SPF, DKIM and DMARC: Email Authentication Setup Guide

Configuring SPF, DKIM and DMARC correctly is the foundation of email authentication: these are the three records published in DNS that prove to a receiving server that a message sent on behalf of your domain is legitimate and not a forgery. This is a pure deployment guide. It does not cover the attack side (the guide on what is spoofing: types and techniques does that), but the exact records you must publish, how to enable them in Google Workspace and Microsoft 365, and how to move from a permissive policy to one that actively rejects spoofed mail without breaking legitimate email.

The essentials: SPF authorises servers by IP, DKIM signs the message cryptographically, and DMARC requires one of the two to be aligned with the visible From header and decides what to do when it is not. The end goal is p=reject, but you get there in phases (none, quarantine, reject) by reading the aggregate RUA reports so you never discard valid mail during the transition.

What SPF, DKIM and DMARC each authenticate (and why alignment matters)

The three mechanisms solve different problems and only work together.

SPF (Sender Policy Framework) publishes in DNS the list of servers authorised to send mail for your domain. The receiver compares the source IP against that list and validates the envelope domain (MAIL FROM or Return-Path), not the From header the user sees.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the headers. The sending server signs with a private key and the receiver verifies it against the public key published in a DNS selector. If the message arrives intact, the signature is valid.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the decision layer. It checks that SPF or DKIM passes and that the validated domain is aligned with the domain in the visible From header. Alignment is the key piece: an attacker can pass SPF with a domain of their own, but cannot align that domain with your From. DMARC also publishes the policy to apply when alignment fails, plus an address to receive reports.

Without DMARC, SPF and DKIM offer little protection against direct domain impersonation, because they validate fields the user never sees. This nuance is detailed in the guide on types of phishing, where email fraud (BEC) exploits exactly that gap.

DNS records you need to publish

Everything is configured in the domain's DNS zone. These are the exact records.

SPF: the authorised servers record

A single TXT record at the domain root. For Google Workspace:

v=spf1 include:_spf.google.com ~all

For Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

If you send from several platforms (for example corporate mail plus a marketing tool), you chain the include mechanisms: v=spf1 include:_spf.google.com include:sendgrid.net ~all. The final qualifier matters: ~all is softfail (recommended during rollout) and -all is hardfail (stricter). Never use +all, which authorises anyone. There must be only one SPF record per domain, and it must not exceed 10 DNS lookups.

DKIM: cryptographic signature of the mail

DKIM is published under a selector, a subdomain of the form selector._domainkey.yourdomain.com. The TXT record syntax is:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...

In Google Workspace you generate the key (2048 bits recommended) from the admin console and publish the TXT it gives you. In Microsoft 365 the model is different: two CNAME records are published that delegate to Microsoft infrastructure and allow key rotation without touching your DNS:

selector1._domainkey  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

DMARC: the policy that ties it together

A TXT record at _dmarc.yourdomain.com. To start in monitoring mode:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=s; aspf=s; pct=100

Relevant tags: p is the policy (none, quarantine, reject), rua receives the daily aggregate reports, ruf the per-message forensic ones, adkim and aspf set the alignment mode (s strict, r relaxed), and pct the percentage of mail the policy applies to. Always start at p=none.

Setup in Google Workspace and Microsoft 365

The platform steps are concrete and differ between providers.

Google Workspace

1. SPF already covers Google infrastructure through include:_spf.google.com; just publish the TXT in your DNS.
2. In Apps > Google Workspace > Gmail > Authenticate email, generate the DKIM key per domain (choose 2048 bits), publish the indicated TXT, and return to click Start authentication.
3. Publish the _dmarc record at p=none and wait for the first RUA report (24 to 48 hours).

The most common mistake is forgetting the DKIM activation step after publishing the TXT: the key is published but Google does not sign until you click the button. This kind of configuration is part of the continuous defence approach described in how to avoid phishing.

Microsoft 365

1. Add include:spf.protection.outlook.com to your SPF.
2. In the Microsoft Defender security centre > Policies > DKIM, select the domain and enable signing; the portal shows you the two CNAMEs to publish before enabling it.
3. Publish the _dmarc record at p=none. Microsoft 365 does not create the DMARC record for you: it must be published manually in your DNS.

Staged rollout: from p=none to p=reject

The monitoring phase is non-negotiable. Jumping straight to p=reject discards legitimate mail from SaaS providers (billing, e-signature, CRM, newsletters) that send on your behalf and that you have not yet aligned.

1. p=none: publish the policy and let it run for two or three weeks. The RUA reports arriving at the rua address list every source sending as your domain, with its volume and its SPF/DKIM result. A report viewer (Dmarcian, Postmark, URIports or similar) turns them into a readable table.
2. Fix the misaligned flows: for each legitimate source that shows up failing, add it to SPF or enable its DKIM. If a provider cannot DKIM-sign over your domain, delegate a dedicated subdomain (mkt.yourdomain.com) to isolate that flow.
3. p=quarantine; pct=25 and raise the percentage gradually. Quarantine sends unaligned mail to spam, a reversible failure that does not yet destroy messages.
4. p=reject: once the reports show that 100% of legitimate mail is aligned, move to reject. This is the dmarc policy of reject, the only state that actively prevents mail spoofing your domain from being delivered.

Troubleshooting: "dmarc policy not enabled" and misaligned flows

External checkers return warnings with specific causes.

"dmarc policy not enabled": it means the analyser finds no applicable DMARC policy. The usual causes are that no TXT record exists at _dmarc.yourdomain.com, that the p tag is missing or set to p=none (which many scoring tools treat as not applied), or that the record has a syntax error and does not parse. Verify with dig TXT _dmarc.yourdomain.com +short that it returns exactly one record starting with v=DMARC1 and that p has a value. To clear the warning for real you must reach quarantine or reject.

SPF passes but DMARC fails: this is misalignment. The envelope (MAIL FROM) uses a provider domain that passes SPF but does not match your From. The fix is aligned DKIM signing, which survives forwarding, or relaxing aspf if the envelope subdomain is under your control.

Forwarding breaks SPF: mailing lists and forwarding rules change the source IP. DKIM is unaffected if the body is not altered, so strong DKIM keeps DMARC passing when SPF fails. Do not switch to -all prematurely for this reason.

"Too many DNS lookups": SPF exceeds the 10 permitted lookups. Consolidate include mechanisms, remove providers you no longer use, or flatten the record with a flattening tool.

Advanced: BIMI and VMC once you are at p=reject

With DMARC at quarantine or reject at 100% you can enable BIMI (Brand Indicators for Message Identification), which shows your brand logo next to the sender in compatible clients such as Gmail and Apple Mail. The record:

default._bimi.yourdomain.com  TXT  "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"

The logo must be in SVG Tiny Portable/Secure format. The a tag points to a VMC (Verified Mark Certificate), a certificate issued by authorities such as DigiCert or Entrust that binds the logo to a registered trademark. Gmail requires the VMC to render the logo. BIMI adds no extra cryptographic security, but it reinforces visual recognition and is a tangible incentive to complete the rollout to p=reject.

Frequently asked questions

How do I set up DMARC from scratch?

Publish SPF and DKIM first and confirm both pass. Then create a TXT record at _dmarc.yourdomain.com with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Leave p=none for two or three weeks while reading the RUA reports, fix the misaligned flows, and only then move up to quarantine and reject.

What does "dmarc policy not enabled" mean?

It means the checker finds no effective DMARC policy. Either the _dmarc record is missing, or it has a syntax error, or the p tag is absent or set to none. Check with dig TXT _dmarc.yourdomain.com +short and make sure there is a single record starting with v=DMARC1 and a valid value in p. The warning clears when you apply quarantine or reject.

What is the Google Workspace SPF record?

v=spf1 include:_spf.google.com ~all as a single TXT record at the domain root. If you send from other platforms, add their include mechanisms to the same record before the ~all, without exceeding 10 DNS lookups or creating a second SPF record.

Is it dangerous to set DMARC to p=reject?

Only if done without a prior phase. Applied after weeks of monitoring at p=none and fixing every legitimate flow, p=reject is safe and is the recommended state. The risk appears when you skip monitoring and discard mail from providers that send on your behalf without being aligned.

Do I need BIMI to be protected?

No. BIMI is a visual layer that requires DMARC already in enforcement and a paid VMC certificate. Real protection comes from SPF, DKIM and DMARC at reject. BIMI adds brand recognition, not additional technical security.

Related resources

• What is spoofing: types and techniques
• How to avoid phishing
• Types of phishing
• What is social engineering

Set up your email authentication with Secra

Secra audits your organisation's SPF, DKIM and DMARC configuration, identifies the SaaS flows that send on your behalf without being aligned, and guides the transition from p=none to p=reject without interrupting legitimate mail, with continuous monitoring of the aggregate reports. This work is part of our managed cybersecurity service and provides direct documentary evidence if your organisation falls within the scope of NIS2 or needs to justify measures under Article 32 of the GDPR. Write to us through contact for an initial assessment of your email posture.