SPF, DKIM And DMARC Explained For Email Marketers

Email authentication is not a nice-to-have technical project that sits separately from marketing. It is part of whether subscribers receive the campaigns they asked for, whether mailbox providers can distinguish your brand from an impersonator, and whether your sending reputation can be assessed fairly.

The three acronyms to know are SPF, DKIM and DMARC. They work together, but they do different jobs:

• SPF says which servers may send mail for a domain used in the email’s technical envelope.
• DKIM adds a cryptographic signature that lets a receiving server verify responsibility for a message and detect certain changes made after signing.
• DMARC checks whether SPF and/or DKIM authenticate a domain that aligns with the visible From: address, then publishes your requested handling for failures and a destination for reports.

Authentication does not guarantee inbox placement. Mailbox providers also consider complaints, engagement, list quality, sending patterns, content and infrastructure. But unauthenticated or misaligned email makes every one of those other deliverability efforts harder. Gmail requires all senders to use SPF or DKIM, and bulk senders must use SPF, DKIM and DMARC; Yahoo sets similar requirements for bulk senders. (Google’s sender guidance)

The Three Email Identities Marketers Need To Recognise

Confusion usually begins because one email can contain several domains. A subscriber might see:

From: Northstar Outdoors <offers@example.com>

Behind the scenes, the message may also contain:

• The visible From domain: example.com. This is the address subscribers see and reply to. DMARC is centred on this identity.
• The envelope sender or MAIL FROM domain: commonly used for bounces and often shown in the delivered message as Return-Path. SPF normally validates this domain.
• The DKIM signing domain: the value after d= in the DKIM-Signature header.

These domains do not have to be identical. However, to pass DMARC, the visible From domain must align with an SPF-authenticated envelope domain or a DKIM-authenticated signing domain. This makes it much harder for someone to send a message that looks as though it came from your brand merely by putting your domain in the visible From address. (RFC specification)

SPF: Permission To Send From The Envelope Domain

Sender Policy Framework (SPF) is a DNS TXT record. It lists the services and servers permitted to send mail using a domain in the SMTP envelope. When a mailbox provider receives a message, it compares the connecting server’s IP address with that published policy.

A simplified SPF record might look like this:

example.com. TXT "v=spf1 include:mail-provider.example ip4:192.0.2.10 -all"

This is illustrative only. Never copy an SPF record without replacing the mechanisms with the exact values supplied by your own providers.

What SPF Does Well

• It authorises sending infrastructure for the relevant envelope domain.
• It helps recipients reject or distrust messages sent from an unauthorised server.
• It is useful for services that use a branded bounce domain.

What SPF Cannot Do

SPF does not authenticate the visible From: address on its own. A message can pass SPF for a provider-owned bounce domain while displaying your brand’s domain in the From line. That is why SPF alone is insufficient for brand-level protection, and why DMARC alignment matters.

SPF can also break in ordinary marketing operations. Every service that sends as your domain must be accounted for: your campaign platform, transactional mail service, helpdesk, ecommerce system, corporate mailbox provider and any agency or legacy system still sending on your behalf. SPF has a limit of ten DNS-querying terms during evaluation. Overly complicated chains of include, a, mx, exists or redirect mechanisms can therefore produce an SPF permerror. (RFC specification)

SPF Rules That Prevent Avoidable Problems

• Publish one SPF record per domain. Multiple SPF TXT records can cause a permanent error.
• Keep an owner’s inventory of every authorised sender, including who can approve additions or removals.
• Use the provider’s documented SPF include value rather than guessing IP addresses.
• Do not remove an old provider until you have confirmed it no longer sends mail, including automated operational messages.
• Treat SPF as infrastructure hygiene, not as the sole way to achieve DMARC alignment.

DKIM: A Signed Message With A Published Public Key

DomainKeys Identified Mail (DKIM) works differently. Before a message is sent, the sending service uses a private key to create a signature over selected headers and the message body. The recipient retrieves the matching public key from DNS and verifies the signature.

The signature will include fields such as:

DKIM-Signature: ... d=example.com; s=ef2026; ...

Here, d=example.com is the signing domain and s=ef2026 is the selector: a label that points to the public-key DNS record, normally at ef2026._domainkey.example.com. Selectors allow a domain to operate more than one key, rotate keys, and move gradually between sending systems.

Why DKIM Is Particularly Valuable For Marketing Email

DKIM gives a receiving provider a durable, domain-level identifier for the message stream. Unlike SPF, it can still pass after forwarding in situations where the forwarder’s server is not authorised in the original sender’s SPF record. It is also commonly the simplest route to DMARC alignment when a platform uses its own envelope sender domain but signs using your branded domain.

DKIM verifies that the signed portions of a message have not changed in transit in a way that invalidates the signature; it is not a statement that the message is wanted or safe. The core DKIM specification defines the signature and selector mechanism, while the later cryptographic update requires signers to use stronger modern algorithms and key sizes. Gmail says that mail sent to personal Gmail accounts needs a DKIM key of at least 1,024 bits and recommends 2,048 bits where supported. (RFC specification)

DKIM Checks For Marketers And Technical Teams

• Ensure the campaign platform signs with your intended domain or a subdomain that aligns with the visible From domain.
• Use 2,048-bit keys where your DNS provider and sending service support them.
• Keep a record of the selector, provider, date introduced and key-rotation owner.
• Do not change templates, tracking rewrites or mail-routing rules after a service has signed the message unless you know the signature will remain valid.
• During a platform migration, confirm that the new platform’s selector exists in DNS before any volume is sent.

DMARC: Alignment, Policy And Visibility

Domain-based Message Authentication, Reporting and Conformance (DMARC) brings SPF and DKIM into a brand-protection framework. It looks at the domain in the visible From header and asks two questions:

1. Did SPF or DKIM pass?
2. Does the domain that passed align with the visible From domain?

A message passes DMARC when at least one of SPF or DKIM both passes and aligns. Bulk-sender requirements can separately ask senders to deploy both SPF and DKIM, but the DMARC pass calculation itself requires one aligned passing identifier. (RFC specification)

In May 2026, RFC 9989 replaced the earlier RFC 7489 as the core DMARC specification, with separate specifications for aggregate and failure reporting. The practical concepts marketers work with remain familiar: a DNS record, aligned authentication, a requested policy, and feedback reports. (RFC specification)

Understanding Alignment: The Critical Detail

Relaxed alignment allows organisational-domain matches. For example, a visible From address at news.example.com can align with a DKIM signature using d=example.com. Strict alignment requires an exact domain match.

For most marketing programmes, relaxed alignment is a sensible starting point because it accommodates well-managed subdomains. Strict alignment can be appropriate when a security team has fully mapped every authorised stream and has a clear reason to require exact matches. It is not automatically “better”; it is less forgiving of legitimate variation.

DMARC Policies: None, Quarantine And Reject

A basic record is published at _dmarc.example.com. For example:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The key policy options are:

Policy	Meaning	Best Use
p=none	Requests monitoring without asking receivers to quarantine or reject failed mail.	Discovery and remediation.
p=quarantine	Requests suspicious failed mail be treated cautiously, often by placing it in spam.	Gradual enforcement after legitimate streams are understood.
p=reject	Requests failed mail be rejected.	Strongest anti-spoofing posture once legitimate sending is reliably aligned.

A DMARC policy is a request to receivers, not a universal delivery guarantee. Receivers make their own filtering decisions and may handle a message differently in unusual situations, such as forwarding or mailing-list modification. (RFC specification)

DMARC Reports: Your Inventory Of Who Sends As You

The rua tag requests aggregate reports. These are machine-readable XML summaries sent by participating receivers, typically showing source IPs, volumes, SPF and DKIM results, alignment and applied policy. They are not a campaign performance report; they are an authentication intelligence feed.

For a marketer, the useful questions are simple:

• Which services are sending mail that claims to be from our domain?
• Are they authorised and expected?
• Which legitimate streams fail SPF, DKIM or alignment?
• Are unknown sources attempting to impersonate us?

Use a reporting service or have a technical colleague interpret the XML. The important operational habit is assigning somebody to review anomalies and turn findings into actions. Aggregate reporting is specifically designed to give domain owners visibility into real-world mail streams before policy decisions are made. (IETF specification)

A Safe DMARC Rollout For A Marketing Programme

1. Choose the domain strategy. Decide which domain subscribers see in the From address. If you use a dedicated marketing subdomain, make the choice deliberate and maintain the same brand relationship.
2. Inventory every sender. Include campaigns, transactional messages, staff mail, forms, customer-support tools, ecommerce notifications and old integrations. Ask each supplier which domain it uses for SPF, which domain it uses for DKIM, and which DNS records it requires.
3. Configure SPF and DKIM first. Validate them on a real delivered message, not only in a provider setup screen.
4. Publish DMARC at p=none with aggregate reporting. This establishes visibility without risking an immediate block on a forgotten legitimate service.
5. Review reports over normal sending cycles. Include monthly invoices, abandoned-basket messages, seasonal campaigns and messages sent by different departments. Resolve every legitimate failure before enforcement.
6. Move carefully to enforcement. Start with p=quarantine, use percentage sampling where appropriate, and monitor results. Progress to p=reject when legitimate aligned mail is consistently understood and controlled.
7. Make authentication part of change control. Any new sending vendor, domain, subdomain, selector, tracking-domain change or acquisition of another brand should trigger an authentication review.

Google’s rollout guidance similarly recommends having SPF and DKIM in place before DMARC, monitoring reports, then moving gradually towards quarantine after a period without outgoing-mail issues. (Google’s sender guidance)

How To Check A Real Campaign

Send a test campaign to accounts at more than one mailbox provider. Open the full message headers, then look for an Authentication-Results header. You want to see results broadly like:

spf=pass ...
dkim=pass header.d=example.com
dmarc=pass header.from=example.com

Do not stop at the word pass. Confirm that the visible From domain is the one you intended, the DKIM d= domain is branded and aligned, and the envelope sender is expected. A successful test from one provider is useful, but ongoing monitoring matters because new systems and DNS edits can create failures later.

Email Foundry users can make this a repeatable pre-send task by pairing authenticated SMTP configuration with Advanced Campaign Preflight & Inbox Risk checks, then investigating persistent issues through deliverability diagnostics. Its tracking-domain and link-reputation monitoring are also relevant because authentication proves identity, while links still contribute to how a message is evaluated.

Common Failures And What They Usually Mean

Symptom	Likely Cause	Practical Next Step
SPF fails	A new vendor or server is absent from the SPF policy; a lookup limit has been exceeded; or the envelope domain is unexpected.	Inspect the Return-Path and sending IP, then compare them with the published SPF record and provider documentation.
DKIM fails	Missing or malformed selector record, DNS propagation issue, wrong key, or message modification after signing.	Check the d= and s= values in headers, then query the matching selector record.
SPF and DKIM pass, but DMARC fails	Neither passing domain aligns with the visible From domain.	Usually configure branded DKIM signing, or align the envelope sender domain where supported.
DMARC reports show an unknown source	It may be a forgotten system, a supplier, forwarded mail, or an impersonation attempt.	Identify it before authorising it. Do not add an SPF include merely to make the report look cleaner.
Authentication passes, but campaigns reach spam	Authentication is correct but reputation, complaints, inactive addresses, message relevance or sending behaviour are weak.	Review consent, suppression, engagement, complaint signals, frequency and send pacing alongside technical results.

Practical Action Plan

1. This week: send a live test, inspect headers, and record the visible From domain, envelope domain, DKIM signing domain and authentication outcomes.
2. Next: create one authoritative inventory of all systems that send as your organisation. Give it a named owner and a review date.
3. Then: fix SPF and DKIM for every legitimate sender, prioritising the domains used for customer-facing campaigns and transactional messages.
4. Publish: add a DMARC p=none record with an aggregate-report destination that someone actively reviews.
5. Monitor: investigate unknown sources and alignment failures across a complete business cycle, rather than only after one successful campaign.
6. Enforce: move in measured stages to quarantine and then reject only after legitimate mail has been accounted for.
7. Keep it healthy: combine authentication monitoring with list hygiene, a clear preference centre, one-click unsubscribe, sensible frequency controls and engagement-based suppression. Authentication establishes your identity; respectful sending helps protect the reputation attached to it.

Frequently asked questions

Do SPF, DKIM And DMARC Guarantee Inbox Placement?

No. They establish and protect sender identity, but mailbox providers also consider complaints, engagement, list quality, content, links and sending behaviour.

Do I Need SPF, DKIM And DMARC If I Send Small Volumes?

Yes. Gmail and Yahoo require baseline authentication for all senders, while their additional bulk-sender requirements make a complete SPF, DKIM and DMARC setup especially important at scale.

Can An Email Pass SPF And DKIM But Fail DMARC?

Yes. This happens when the passing SPF envelope domain and DKIM signing domain do not align with the domain in the visible From address.

Should I Start DMARC With p=reject?

Usually no. Start with p=none and aggregate reports, identify every legitimate sending stream, then move gradually through enforcement as appropriate.

What Is DMARC Alignment?

It is the relationship between the visible From domain and the domain authenticated by SPF or DKIM. At least one authenticated domain must align for DMARC to pass.

Why Is DKIM Often Better Than SPF For DMARC Alignment?

A sending platform can usually sign with a branded DKIM domain even when it uses its own envelope sender domain for bounce handling. DKIM may also survive some forwarding scenarios where SPF does not.

What Are DMARC Aggregate Reports?

They are machine-readable summaries from participating receivers showing the sources that sent mail claiming to be from your domain and how SPF, DKIM and DMARC evaluated those messages.

Sources and further reading

• Email Sender Guidelines — Google
• Sender Best Practices — Yahoo Sender Hub
• RFC 7208: Sender Policy Framework (SPF) For Authorizing Use Of Domains In Email, Version 1 — RFC Editor
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• RFC 8301: Cryptographic Algorithm And Key Usage Update To DKIM — RFC Editor
• RFC 9989: Domain-Based Message Authentication, Reporting, And Conformance (DMARC) — RFC Editor
• RFC 9990: DMARC Aggregate Reporting — IETF