Email Security

Set Up SPF, DKIM, and DMARC

Protect your sending domain from direct spoofing through a staged rollout that checks legitimate senders before enforcing rejection.

Content review: 2026-09-22 · Estimated effort: Medium

Priority and effort are editorial starting points, not calculated risk or mandatory deadlines. Adapt to business impact, vendor instructions, available licenses, and applicable obligations. Test changes before broad rollout.

Before you start

Before starting: obtain authorized DNS and email-administrator access. Export existing records, identify the rollback owner, and inventory every sender: business mail, marketing, invoicing, ticketing, and website forms. Include sending subdomains. Follow each provider's current instructions; Microsoft examples must not be copied into a Google or Zoho setup.

Put it into practice

SPF identifies permitted sending systems. Maintain one SPF TXT record per sending domain or subdomain, combining only approved providers. Check the 10 DNS-lookup evaluation limit, including nested includes; do not publish a second SPF record or use +all. Do not change MX records just to configure authentication.
DKIM adds a verifiable signature. Generate or obtain each provider's domain-specific DNS records and enable signing after validation. Microsoft 365 supplies two CNAME selector targets; other providers may use TXT records. Copy the supplied values, not sample keys or invented targets. Keep private signing keys secret.
DMARC checks alignment with the visible From domain: at least one passing SPF or DKIM result must align under the policy's alignment mode. Configure a _dmarc TXT record, initially with p=none for monitoring and an approved aggregate-report destination. Confirm the mailbox or reporting service works. Monitoring alone does not request blocking; DNS record presence alone is not success.
Review aggregate reports and headers from every legitimate sender over representative business cycles, including occasional invoices and campaigns. Fix unauthorized or misaligned sources. Reports contain infrastructure metadata: restrict access, agree retention, and review any third-party processor before sending reports there. Do not enable forensic/failure reports without a separate privacy review.
Once legitimate flows are validated, progress carefully to quarantine and then reject, monitoring delivery and support requests at each stage. Review subdomain policy effects as well. If valid mail is affected, use an approved temporary policy rollback while fixing alignment; preserve SPF/DKIM and account protections.
Verify: send harmless messages from each approved system to an external test inbox and inspect Authentication-Results for SPF, DKIM, DMARC, and alignment. Confirm public DNS values and report receipt, and repeat after vendor changes. Record results and unresolved senders. These controls do not stop lookalike domains, compromised legitimate accounts, or all phishing.

Make a start

Tools and templates

Start with what you already have. “Included” means part of an existing eligible product or subscription, not a free standalone service. Options reviewed 2026-09-22; check current vendor terms before choosing.

Start without another software subscription

Configure authentication through existing DNS and mail-provider controls. Inventory senders in Excel and review approved reports without buying a reporting dashboard.

Where this stops: Provider charges and reporting storage may still apply. A free DNS lookup cannot establish that every legitimate sender aligns or replace ongoing report review.

See the official sources and eligibility details below. Free software can still require equipment, storage and staff time.

Your DNS provider and Microsoft 365 email authentication settings

Use existing DNS and email services; reporting services may cost extra

Inventory senders in the worksheet, then follow your mail provider’s domain-specific SPF/DKIM instructions and stage DMARC monitoring before enforcement.

Limits: Microsoft instructions apply to Microsoft 365. Do not copy sample DNS records into another provider. A reporting mailbox or service must be approved and working before publishing its address.

Your information: DNS records are public; DMARC reports contain infrastructure metadata. Do not use third-party header/report analyzers with confidential mail without approval.

Official instructions: Your DNS provider and Microsoft 365 email authentication settings ↗

Download a working template

Free to download and adapt for your team. Open CSV files in Microsoft Excel using your existing Office license; Markdown files open in a text editor such as Notepad. Save an Excel Workbook (.xlsx) copy if you add formatting. These are manual worksheets, with no macros, scoring or automatic verification.

Email sender and authentication inventory (CSV) ↓
List every legitimate sending service, including occasional invoices and campaigns. Record observed SPF, DKIM and DMARC alignment; do not paste private keys or message bodies.
Security change and verification record (CSV) ↓
Plan one scoped change per row, including prerequisites, recovery, test expectations and actual results. An untested change is not a verified success.

Fictional worked example

Illustration only. This is not a customer story, lab result, or evidence that your environment is protected. Replace the example entries and record your own observations.

A business uses Microsoft 365 plus a separate invoicing service to send email.

Use the Email sender and authentication inventory template.

What to enter before testing

Sender or service: EXAMPLE: invoicing provider
Business purpose: Customer invoices
DMARC alignment result: Not verified
Issue and next action: Check provider instructions and an authorized test message

How to verify

Record each sender separately. Use harmless test mail and approved report access to inspect SPF, DKIM and DMARC alignment for the actual sending domain. Confirm occasional senders too before increasing enforcement. Keep message bodies and private keys out of the worksheet.

If the result is unexpected

If the invoice sender fails alignment, keep rollout staged and correct its configuration using its provider instructions. An SPF pass alone does not establish DMARC alignment. Do not copy invented DNS records or enforce rejection before legitimate senders are accounted for.

Save completed worksheets privately. They can describe security gaps, systems and people. Do not include passwords, recovery keys or confidential message content. This site does not receive your edits; a cloud editor or synced folder may send them to its provider.

Sources and review approach

Original small-team guidance with selected NIST CSF 2.0 alignments, not an official crosswalk or a complete framework implementation. These instructions are a starting point, not a claim of testing in your environment.

NIST CSF 2.0: PR.PS-01: managed email and DNS configuration

How this guidance is prepared