Email Authentication Explained: SPF, DKIM And DMARC

Email authentication is the technical foundation of a trustworthy sending identity. It does not guarantee inbox placement, make weak campaigns welcome or replace good list management. It does, however, let receiving mail systems verify important claims about a message: whether the sending server was authorised, whether the message was signed by a domain, and whether either of those identities matches the brand domain a recipient sees in the From: line.

That matters for both security and deliverability. Gmail requires all senders to use SPF or DKIM and, for senders delivering more than 5,000 messages a day to personal Gmail accounts, requires SPF, DKIM and a DMARC record. Its current guidance also says that non-compliant traffic may be spam-foldered, rate-limited or rejected. Yahoo has similar requirements for bulk senders, including DMARC and alignment. (Google’s sender guidance)

This guide explains the three standards in plain English, shows how they fit together, and sets out a safe way to implement them without accidentally disrupting legitimate mail.

The short version

Standard	What it checks	Where it is published	What it cannot do alone
SPF	Whether the server sending a message is allowed to use the envelope-sender domain.	A DNS TXT record.	It does not, by itself, prove that the visible From: domain is genuine.
DKIM	Whether a domain signed the message and whether signed parts were altered afterwards.	A public key in DNS; the private key stays with the sender.	A valid signature alone does not mean the visible From: domain matches the signer.
DMARC	Whether SPF or DKIM passed and aligned with the visible From: domain; it also publishes requested handling and reporting instructions.	A DNS TXT record at _dmarc.	It cannot fix poor consent, unwanted content, complaints or a weak sending reputation.

Think of SPF as a list of authorised sending routes, DKIM as a tamper-evident domain signature, and DMARC as the rule that connects those technical checks to the address recipients actually see.

First, understand the identities in an email

A common source of confusion is that one message can contain several domain names. Authentication works properly only when you know which one each protocol examines.

• Visible From address: the address displayed to the recipient, such as offers@example.co.uk. This is the RFC 5322 From: header and is the identity DMARC protects.
• Envelope sender: the address used during the SMTP delivery conversation, often shown afterwards as Return-Path. It receives bounces and is the identity SPF normally checks.
• DKIM signing domain: the domain in the DKIM signature’s d= tag. A message can have more than one DKIM signature.
• Sending IP address: the server that actually handed the message to the recipient’s provider.

For example, a retailer may send a campaign showing news@northstar.co.uk, use bounce.mail.northstar.co.uk as its envelope sender, and apply a DKIM signature with d=northstar.co.uk. That can be a strong setup: the visible brand domain is aligned with the DKIM signing domain and is closely related to the envelope-sender domain.

By contrast, a campaign showing news@northstar.co.uk but signed only by d=email-platform.example may have a valid DKIM signature without passing DMARC for northstar.co.uk. The crucial missing element is alignment.

SPF: authorising the sending server

Sender Policy Framework (SPF) is a DNS-based authorisation record. A receiving server takes the IP address that connected to it, looks at the envelope-sender domain (or, in some cases, the HELO/EHLO identity), and checks whether that IP is permitted by the published SPF record. The SPF standard defines the domain being checked as the domain from the SMTP MAIL FROM or HELO identity, not automatically the visible From: address. (RFC specification)

What an SPF record looks like

example.co.uk. TXT "v=spf1 include:spf.your-workspace.example include:spf.your-email-platform.example -all"

This is an illustrative record only. The actual include: values must come from each provider’s documentation. The final -all says that servers not matched by an earlier mechanism are unauthorised. Some organisations begin with ~all while they audit their senders, but it is better to treat that as a short transition, not a permanent substitute for maintaining an accurate record.

SPF rules that prevent costly mistakes

• Publish one SPF record per hostname. Multiple TXT records beginning v=spf1 can cause a permanent error. Consolidate the permitted services into one record.
• Inventory every sender before tightening the record. This includes Microsoft 365 or Google Workspace, a marketing platform, helpdesk, CRM, ecommerce system, invoicing tool, website form handler and any server sending alerts.
• Respect the DNS lookup limit. SPF evaluation permits a maximum of ten DNS-querying terms, including mechanisms such as include, a and mx, plus redirect. Exceeding it produces permerror, so adding every supplier without checking the expanded lookup count can break SPF. (RFC specification)
• Do not use SPF as your only defence. Forwarding commonly changes the apparent sending IP address, which can make SPF fail even when the original email was legitimate. This is one reason DKIM is essential. (Google’s sender guidance)

DKIM: signing the message with your domain

DomainKeys Identified Mail (DKIM) adds a digital signature to an email header. The sending system signs selected headers and, usually, the body using a private key. The receiving system fetches the corresponding public key from DNS and verifies the signature. A successful result demonstrates that the signing domain authorised that signature and that the signed material was not modified after signing. (RFC specification)

A DKIM signature contains useful fields, including d= for the signing domain and s= for the selector. The receiver uses them to look up a DNS record such as:

ef2026._domainkey.example.co.uk. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

The selector lets a domain publish multiple keys at once. That is useful for key rotation, separating systems, or moving between suppliers without a risky all-at-once change.

DKIM choices that matter in practice

• Sign with a domain you control. Ideally, use the same organisational domain as the visible From: address. A branded DKIM domain is usually more robust for DMARC alignment and gives you control if you change sending providers.
• Use a sufficiently strong key. Gmail and Yahoo require DKIM keys of at least 1,024 bits and recommend 2,048 bits where supported. (Google’s sender guidance)
• Rotate keys deliberately. Add and test a new selector before retiring the old one. Removing an old public key while mail signed with it is still in transit can create avoidable failures.
• Avoid post-signing changes. Gateways, mailing lists and forwarding systems that rewrite the subject, body encoding, MIME boundaries or signed headers can invalidate DKIM. (Google’s sender guidance)

In Email Foundry, configure and validate the custom DKIM domain for each sending route rather than relying solely on a platform-owned signing identity. This is particularly important where campaigns, transactional messages and local-MTA or SMTP routes coexist: each route should be tested to confirm it produces the expected aligned signature.

DMARC: alignment, policy and visibility

Domain-based Message Authentication, Reporting and Conformance (DMARC) sits above SPF and DKIM. It asks two questions:

1. Did SPF or DKIM pass?
2. Did the passing identity align with the domain in the visible From: address?

To pass DMARC, a message needs at least one passing and aligned method: SPF, DKIM or both. It does not require both methods to align for every individual message, although having both aligned gives useful resilience. Gmail’s bulk-sender guidance requires SPF and DKIM overall, while stating that the visible From: domain must align with either the SPF or DKIM domain for direct mail. (Google’s sender guidance)

What alignment means

With relaxed alignment, related subdomains can align. For instance, news.example.co.uk and example.co.uk are ordinarily aligned at the organisational-domain level. With strict alignment, the domains must match exactly. Relaxed alignment is the normal starting point and is accepted by Yahoo for its bulk sender requirements. (Yahoo’s sender guidance)

Alignment is why the details of a sending platform’s custom-domain setup matter. If the visible address is hello@example.co.uk, but the envelope sender remains on an unrelated supplier domain and DKIM signs only with that supplier domain, neither authentication result aligns. SPF and DKIM can look healthy in isolation while DMARC still fails.

What a DMARC record looks like

_dmarc.example.co.uk. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk; adkim=r; aspf=r"

Again, treat this as a pattern, not a record to paste blindly. p=none requests monitoring rather than enforcement; rua is the address for aggregate reports; and adkim=r and aspf=r explicitly set relaxed alignment. Aggregate reports are typically machine-readable XML files summarising which sources attempted to use your domain and how they authenticated.

The policy options are:

• p=none: collect evidence without asking recipients to quarantine or reject failures.
• p=quarantine: request that failing mail be treated with suspicion, often by placing it in spam.
• p=reject: request rejection of mail that fails DMARC.

DMARC gives receivers a published policy and reporting mechanism; it does not oblige every receiver to handle every message identically. The sensible route is therefore to move to enforcement only after reports show that your genuine sending sources are consistently passing and aligned. (RFC specification)

A safe rollout path: monitor, fix, enforce

1. Map the real sending estate

List every system that can send as your domain, including people’s mailbox service and low-volume systems that are easy to forget. Record the visible From: domain, envelope-sender domain, DKIM d= domain, provider, purpose, volume and owner. Include subsidiaries and country domains.

2. Set SPF and DKIM for every legitimate route

Authorise each route in SPF where appropriate, but do not turn SPF into an ever-growing collection of includes. Configure branded DKIM signing for the routes that support it, preferably with 2,048-bit keys. Send a seed message to a Gmail mailbox and inspect the message headers; look for spf=pass, dkim=pass and the expected signing domain.

3. Publish DMARC in monitoring mode

Start with p=none and a working aggregate-report mailbox or reporting service. Do not assume a published record proves success: it only proves that you have asked for monitoring. Review reports over a representative period that includes newsletters, automations, receipts, support mail and peak business activity.

4. Resolve unknown sources and failures

For each source in the reports, decide whether it is legitimate. Legitimate but failing sources need corrected authentication or a different visible From: domain. Unknown sources should not be added to SPF merely because they appear in a report; investigate them as possible unauthorised use.

5. Increase enforcement gradually

Once legitimate traffic is reliably aligned, move towards p=quarantine, using the pct tag if you need a controlled rollout, then progress to p=reject when the evidence supports it. Continue monitoring: new software, agency accounts and acquisitions can introduce unauthenticated mail later.

Common authentication failures and how to diagnose them

Symptom	Likely cause	What to check
SPF shows permerror	Multiple SPF records or too many DNS lookups.	Confirm there is one v=spf1 record and calculate the fully expanded lookup chain.
DKIM is missing	The route is not configured to sign, or the DNS key is absent.	Check the sending route, selector, DNS hostname and public key value.
DKIM fails intermittently	A key was removed too early, DNS is inconsistent, or a downstream system edits signed content.	Compare headers across routes and inspect any gateway, CRM or forwarding step after signing.
SPF and DKIM pass but DMARC fails	The passing SPF domain and DKIM d= domain are unrelated to the visible From: domain.	Configure a custom return-path and/or branded DKIM domain, then verify alignment.
DMARC reports show an unfamiliar sender	It may be an overlooked supplier, forwarding traffic or impersonation.	Identify it before making DNS changes; do not authorise an unknown source by default.
Authentication passes but mail goes to spam	Authentication is only one deliverability signal.	Review consent, complaints, engagement, sending consistency, content and list quality. Gmail and Yahoo both emphasise low complaint rates and sending mail recipients actually want. (Google’s sender guidance)

Practical action plan

1. Choose your primary sending domain. Use a domain that represents your brand and is suitable for long-term sending. Keep the visible From: address consistent by message type.
2. Create a sending inventory. Ask marketing, IT, customer support, finance, ecommerce and agencies which tools send email using your domains.
3. Audit DNS. Check that each sending domain has one valid SPF record, active DKIM selectors and a DMARC record.
4. Align Email Foundry routes. Add the supplied SPF and DKIM DNS records for every relevant Email Foundry sending route, then send test campaigns and automations to confirm the resulting headers are aligned with your visible From domain.
5. Publish DMARC at p=none. Use an aggregate-report destination you actively monitor. Keep a record of who owns that inbox or reporting service.
6. Review reports regularly. Classify every source as approved, misconfigured, retired or unauthorised. Correct configuration before authorising anything new.
7. Move carefully to enforcement. Progress from monitoring to quarantine and then reject only when legitimate traffic is consistently passing and aligned.
8. Keep authentication operational. Re-test after adding a new platform, changing DNS providers, rotating DKIM keys, switching SMTP routes or launching a new subdomain.

Once SPF, DKIM and DMARC are working together, you have a dependable identity layer for your email programme. That gives mailbox providers clearer signals, makes spoofing harder and gives your team the evidence to spot configuration drift before it becomes a deliverability problem.

Frequently asked questions

Do I need SPF, DKIM and DMARC if I send only a small volume of email?

Yes. Gmail requires SPF or DKIM for all senders, and all three standards are sensible baseline protection for any domain that sends email. Smaller senders may not face the same bulk-sender requirements, but spoofing and authentication failures are not limited to high-volume programmes.

Can SPF pass while DMARC fails?

Yes. SPF checks the envelope-sender domain, whereas DMARC checks whether that passing domain aligns with the visible From domain. A supplier-owned return-path often causes this mismatch.

Can DKIM pass while DMARC fails?

Yes. DKIM may validate a signature from a third-party domain, but DMARC requires the signing domain to align with the visible From domain.

Should I start DMARC with p=reject?

Usually no. Start with p=none, inspect aggregate reports, fix legitimate sources and then move gradually towards quarantine and reject. Immediate enforcement can block important but forgotten mail streams.

What is a DKIM selector?

A selector is the label before ._domainkey in the DNS name of a DKIM public key. It allows a domain to publish multiple keys, which supports rotation and separate configurations for different sending systems.

Why is there a ten-lookup SPF limit?

The SPF specification limits DNS-querying mechanisms and modifiers to ten during evaluation. Going beyond the limit returns a permanent error, so complex chains of include records must be managed carefully.

Does passing DMARC guarantee inbox placement?

No. Authentication proves and protects sending identity, but mailbox providers also assess recipient feedback, consent, engagement, content, sending patterns and infrastructure reputation.

Sources and further reading

• Gmail Email sender guidelines — Google
• Yahoo Sender Requirements & Recommendations — Yahoo Sender Hub
• RFC 7208: Sender Policy Framework (SPF) — RFC Editor
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• DMARC Overview — DMARC.org
• Gmail email sender guidelines FAQ — Google