Email Authentication Methods: SPF, DKIM, and DMARC Explained

Email authentication methods are the DNS-based controls that let receiving mail systems verify whether a message was authorized by your domain. For most organizations, the essential stack is SPF, DKIM, and DMARC: SPF authorizes sending infrastructure, DKIM cryptographically signs a message, and DMARC checks whether either result aligns with the visible From domain.

They are not merely deliverability extras. Properly configured authentication reduces straightforward domain spoofing, helps mailbox providers evaluate your mail, and gives you an inventory of systems sending under your name. Major mailbox providers also require authentication for many kinds of mail; Gmail requires SPF or DKIM for all senders to personal Gmail accounts, while high-volume senders need SPF, DKIM, and DMARC. (support.google.com)

What “email authentication” means—and what it does not

Email has several identities. The address a recipient sees in the From: header is not necessarily the domain used in the SMTP envelope sender, the server hostname, or the DKIM signature. Email authentication methods evaluate these machine-readable identities so a receiving system can decide whether the visible sender is credibly connected to the domain owner.

The core protocols answer different questions:

• SPF (Sender Policy Framework): Was the server that delivered this message authorized to use the envelope-sender domain?
• DKIM (DomainKeys Identified Mail): Does a valid cryptographic signature connect this message to a signing domain, and has the signed content remained intact?
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Does SPF or DKIM pass and align with the visible From domain? If not, what handling policy has the domain owner requested?

DMARC is the coordination layer, not a replacement for SPF and DKIM. A passing SPF check alone is not enough for DMARC if SPF authenticated an unrelated domain. The same is true of DKIM: a signature can be technically valid but fail DMARC if its d= domain does not align with the domain in From. The current DMARC core standard describes the protocol as a way for the owner of an email author domain to request validation, publish handling preferences for failures, and request reports. (rfc-editor.org)

Do not confuse sender authentication with user authentication. A password, one-time passcode, magic link, passkey, or multi-factor authentication verifies that a person can access an account. SPF, DKIM, and DMARC verify the claimed source domain of an outbound email. A well-designed password-reset email may use both: strong user authentication in the product and strong domain authentication on the message that delivers the reset link.

Why email authentication methods matter for deliverability and security

Without domain authentication, an attacker can put almost any address in a From header. That makes phishing, fake invoices, executive impersonation, and counterfeit password-reset notices easier to stage. SPF and DKIM add evidence about where a message came from; DMARC adds domain alignment, a published policy, and reporting.

Authentication is also operationally important because modern companies rarely send from one system. Your organization may use Google Workspace or Microsoft 365 for employee mail, an application provider for transactional messages, a customer-support platform, an invoice tool, a recruiting system, and a marketing platform. Each system can create a legitimate message that needs to authenticate correctly.

A DMARC aggregate report can identify IP addresses and authentication outcomes associated with mail claiming to be from your domain. That makes DMARC useful as a discovery mechanism: before enforcing a policy, you can find a forgotten CRM integration, legacy relay, or unauthorized sender. Aggregate reports expose the policy applied and SPF/DKIM outcomes, including alignment information. (rfc-editor.org)

Authentication is necessary but not a delivery guarantee. A correctly authenticated message can still be filtered because of recipient complaints, poor list quality, suspicious content, a new or damaged sending reputation, malformed headers, or other provider-specific signals. The DMARC specification explicitly notes that DMARC does not create privileged delivery for authenticated mail. (rfc-editor.org)

SPF: authorize the servers that send your mail

SPF is a DNS TXT record that names the infrastructure allowed to send mail using a domain in the SMTP envelope sender, commonly shown as Return-Path. It is evaluated by the receiving system against the IP address of the server that actually delivered the message.

A basic SPF record looks like this:

example.com.  TXT  "v=spf1 ip4:198.51.100.25 -all"

This means: the IPv4 address 198.51.100.25 is authorized to send mail for example.com; all other senders should fail. The IP above is a documentation address—replace it with your real outbound relay IP or the include mechanism supplied by your provider.

SPF mechanisms you will actually see

Most SPF records use a small set of mechanisms:

• ip4:203.0.113.10 or ip6:... authorizes a specific sending IP address.
• include:spf.vendor.example delegates a portion of the authorization decision to a provider’s SPF record.
• a authorizes the IP addresses in the domain’s A and AAAA records.
• mx authorizes the hosts listed in the domain’s MX records.
• -all is a hard failure for everything not matched earlier.
• ~all is a soft failure for everything not matched earlier.

For a company using Google Workspace only, Google documents this SPF value:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

That example is only appropriate if Google Workspace is the sole authorized source represented by the record. If your web app, helpdesk, or marketing platform also uses example.com as its envelope sender, their approved authorization must be incorporated into the same SPF record or you should configure those systems to use appropriately authenticated subdomains. Google’s setup guidance confirms that SPF is published as a DNS TXT record and that senders must authenticate mail going to personal Gmail accounts. (support.google.com)

SPF’s limits

SPF does not directly protect the visible From field. A message might show From: billing@example.com while its envelope sender is bounce@mailer.otherdomain.example; SPF can pass for the other domain without proving the visible example.com identity. DMARC solves that gap by requiring alignment.

SPF can also break during ordinary forwarding. A forwarding service sends the message onward from its own IP address, which may not be listed in the original sender’s SPF record. DKIM tends to survive forwarding better when intermediaries do not modify signed portions of the message, which is one reason you should use both SPF and DKIM.

SPF has a DNS-query budget. Receivers must limit SPF evaluation to ten DNS-triggering terms such as include, a, mx, ptr, exists, and redirect; exceeding the overall limit can produce a permanent SPF error. Avoid blindly adding every SaaS vendor’s include: directive to one record. (rfc-editor.org)

SPF rules that prevent common outages

1. Publish one SPF TXT record per domain. Multiple independent records beginning with v=spf1 can produce an SPF permanent error.
2. Use the envelope domain that actually sends the mail. The visible From domain is not the only identity involved.
3. Count includes and nested lookups. A record can appear short while vendor includes consume the lookup budget.
4. Do not copy an IP example from a tutorial. Use your mail provider’s documented values or your own relay’s addresses.
5. Remove authorization only after proving no mail uses it. DMARC reports and mail logs are safer evidence than guesswork.

DKIM: sign messages with a domain-controlled key

DKIM adds a cryptographic signature to an email header. The sending system holds a private key; the receiving system retrieves the corresponding public key from DNS. If signature verification succeeds, the receiver knows that the signing domain took responsibility for the message and that the signed content was not altered after signing.

A DKIM signature normally includes a d= tag for the signing domain and an s= tag for the selector. For example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; ...

The receiver looks up this DNS name:

mail2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

The p= value must be the complete public key generated by your email provider or mail server. Do not make up a key, add spaces inside it unless your DNS interface requires quoted chunks, or paste the private key into DNS. The selector is a label chosen by the signing system, so mail2026, google, s1, and provider-specific selector names are all possible.

DKIM is designed to associate a signing domain with a message, and it intentionally separates the signer’s identity from the address shown as the author. (rfc-editor.org) That design enables DMARC to make the critical alignment decision: a signature from mailer.vendor.example may be valid, but it will not satisfy DMARC for From: notices@example.com unless the domains align under the applicable alignment mode.

DKIM implementation choices

For each sending platform, find its DKIM setup page and determine whether it offers one of these patterns:

• Native domain signing: the provider signs with your exact domain, such as d=example.com.
• Custom DKIM / domain authentication: the provider gives you CNAME or TXT records so it can sign with a domain aligned to yours.
• Vendor-domain signing only: the provider signs with its own domain. This may be technically valid DKIM but usually cannot provide DMARC alignment for your visible From domain.

Most organizations should use a distinct selector for each major sending platform. Separate selectors make key rotation and incident response more manageable: you can retire one provider’s selector without interrupting another system.

DKIM failure modes

DKIM may fail because the DNS key is missing, the selector is wrong, the public key does not match the private key, or the DNS value was truncated or malformed. It can also fail after sending if a forwarding service, mailing list, security gateway, or downstream system changes a signed header or body content.

A practical defense is to have the sender sign stable headers and to test actual delivered messages, not merely DNS. Open a test email in a mailbox provider that exposes raw headers and inspect Authentication-Results. You want to see a successful DKIM result plus a header.d= domain that aligns with the From domain.

DMARC: apply alignment, policy, and reporting

DMARC checks the domain in the RFC 5322 From header—the address recipients see. It passes when either SPF passes and aligns with From or DKIM passes and aligns with From. Both protocols do not need to pass, but running both provides resilience when forwarding or message modification causes one method to fail.

A minimal DMARC record is:

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

The record lives at _dmarc beneath the domain being protected, not at the root hostname. p=none asks receivers to send reports without requesting quarantine or rejection for failing mail. rua identifies where aggregate reports should be sent.

A stricter record might be:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

And a fully enforced organization commonly uses:

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

DMARC policy values

• p=none: monitor. Do not request special handling for mail that fails DMARC.
• p=quarantine: request that receivers treat failing mail suspiciously, often by placing it in spam or junk.
• p=reject: request that receivers reject failing mail.

The receiver ultimately decides how to process mail. DMARC expresses the domain owner’s requested disposition; mailbox providers can apply local policy, forwarding exceptions, or anti-abuse controls.

Relaxed versus strict alignment

DMARC supports relaxed and strict alignment for both SPF and DKIM.

Under relaxed alignment, a related subdomain can align. For example, news.example.com can align with example.com when organizational-domain rules consider them related. Under strict alignment, the domains must match exactly.

The tags are:

adkim=r   # relaxed DKIM alignment
adkim=s   # strict DKIM alignment
aspf=r    # relaxed SPF alignment
aspf=s    # strict SPF alignment

Relaxed alignment is the practical starting point for many organizations because providers often sign or use envelope domains beneath a branded subdomain. Strict alignment can be valuable when your sending architecture is tightly controlled, but turning it on without checking every sender can make legitimate mail fail DMARC.

Subdomain policy

A parent-domain record can instruct receivers how to handle mail from subdomains with sp=:

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

Here, mail from example.com is subject to a reject policy, while subdomains without their own DMARC record request quarantine. Use a distinct DMARC record on a subdomain when it needs a different policy or report destination.

The DMARC standards have evolved from the older RFC 7489 document to the newer DMARC core and reporting RFCs. In practice, keep your records focused on widely implemented tags—v, p, rua, adkim, aspf, and, where needed, sp—and confirm vendor support before adopting less common extensions. (dmarc.org)

A safe SPF, DKIM, and DMARC rollout plan

The dangerous mistake is publishing p=reject first and discovering later that your billing system, support desk, or executive assistant’s delegated mail is unauthenticated. Treat deployment as an inventory and monitoring project.

Step 1: list every legitimate mail stream

Create a simple worksheet with these columns:

The goal is not to make every vendor use the root domain. The goal is to ensure every legitimate stream has aligned SPF or DKIM for the From domain it uses.

Step 2: configure DKIM on every platform

Ask each provider for its custom domain authentication instructions. Add its CNAME or TXT records exactly, enable domain signing in its dashboard, and send a test message. For application mail, coordinate DNS changes and sender configuration with the team that owns your email API setup guides; DNS alone does not cause a platform to start signing with your domain.

Step 3: publish and consolidate SPF

Determine which services actually use your domain in their envelope sender. Combine their valid mechanisms into one record, then calculate the DNS lookup count. If the record is approaching the SPF limit, move a stream to a dedicated authenticated subdomain or change the platform’s custom return-path configuration rather than flattening records blindly.

Step 4: publish DMARC monitoring

Start with p=none and a dedicated aggregate-report mailbox or reporting service:

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

Reports are normally machine-readable XML, often compressed. A DMARC analysis service can make them readable, but a dedicated inbox plus a parser also works. If reports go to a different domain, additional authorization rules can be required, so use a report mailbox under the same protected domain unless you understand the external-reporting setup.

Step 5: resolve unknown or failing sources

Do not assume every report row is legitimate. For each source, determine whether it is:

• an approved service that needs aligned SPF or DKIM;
• a company-owned server with incorrect DNS or signing settings;
• forwarded or mailing-list traffic, which needs careful evaluation;
• an external spoofing attempt that should not be authorized.

Step 6: move to enforcement deliberately

When your known legitimate traffic consistently passes DMARC, move from p=none to p=quarantine, monitor again, then move to p=reject. There is no universal waiting period; the appropriate duration depends on how often each business system sends and whether you have observed its complete sending cycle, including month-end invoices, seasonal campaigns, and emergency alerts.

Worked example: authenticate a SaaS company’s mail domain

Assume Bright Trail Software owns brighttrail.example. It sends employee mail from the root domain and application notices from notify.brighttrail.example. The company uses a dedicated relay with public IP 203.0.113.25 for application mail; this is another documentation IP, so a real deployment must substitute its own authorized infrastructure.

1. Separate mail streams by purpose

Bright Trail decides:

• People send as person@brighttrail.example.
• Product notifications send as alerts@notify.brighttrail.example.
• Marketing sends as hello@news.brighttrail.example.

This structure makes ownership and authentication easier to reason about. A compromise or configuration error in the marketing platform is less likely to affect the application’s authenticated identity.

2. Publish SPF for the application subdomain

The application’s envelope sender is bounce@notify.brighttrail.example, delivered from 203.0.113.25:

notify.brighttrail.example. TXT "v=spf1 ip4:203.0.113.25 -all"

That SPF record applies to the envelope domain, not automatically to the root domain. If Bright Trail’s employee mail uses another service, the root-domain SPF record must be separately designed for that service.

3. Enable a DKIM signer

The application relay signs with d=notify.brighttrail.example and selector btapp1. Its public key record is:

btapp1._domainkey.notify.brighttrail.example. TXT "v=DKIM1; k=rsa; p=PASTE_THE_PROVIDER_GENERATED_PUBLIC_KEY_HERE"

In a real configuration, the application relay retains the matching private key and signs every outbound message. The public key placeholder is deliberately not usable; it must be replaced with the exact generated key.

4. Publish DMARC for the subdomain

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

A message with From: alerts@notify.brighttrail.example, envelope sender bounce@notify.brighttrail.example, and DKIM d=notify.brighttrail.example has two paths to DMARC success: SPF passes and aligns, and DKIM passes and aligns.

5. Test the delivered message

Send a message to a test Gmail account and inspect the original headers. Look for results resembling:

Authentication-Results: ...
  spf=pass smtp.mailfrom=notify.brighttrail.example;
  dkim=pass header.d=notify.brighttrail.example;
  dmarc=pass header.from=notify.brighttrail.example

The exact formatting differs by receiver, but the success condition is clear: dmarc=pass, with a From domain matching the domain you intended to protect. Then send tests to a second mailbox provider and check your DMARC aggregate reports after they arrive.

How to verify that authentication is working

DNS validation and message validation are different checks. A DNS query tells you whether a record is publicly available. It does not prove that your mail platform is using the configured domain, selector, or envelope sender.

Check DNS records directly

From a terminal, query TXT records:

dig +short TXT brighttrail.example
dig +short TXT btapp1._domainkey.notify.brighttrail.example
dig +short TXT _dmarc.notify.brighttrail.example

Confirm that the SPF record begins with v=spf1, the DKIM public key exists at the expected selector hostname, and the DMARC record begins with v=DMARC1. DNS changes can take time to appear because resolvers cache records according to TTL, so verify against public DNS after publishing.

Check message headers

Send a fresh message from every platform, then inspect the raw source. Search for:

• Authentication-Results
• spf=pass or a meaningful failure explanation
• dkim=pass and the header.d= value
• dmarc=pass and the header.from= value
• Return-Path, which shows the envelope-sender identity
• DKIM-Signature, which shows the d= domain and selector s=

Do not test only the sender’s own mailbox. Your platform may display optimistic local status before another provider evaluates the message. Test across the mailbox providers that matter most to your customers.

Monitor mailbox-provider diagnostics

For Gmail traffic, Postmaster Tools provides dashboards for authentication, spam rate, delivery errors, and sender-requirement compliance. Its compliance dashboard evaluates SPF/DKIM for all senders and includes DMARC status for bulk senders. (support.google.com) Yahoo also publishes sender guidance that describes DMARC as the mechanism for signaling what to do when neither aligned SPF nor DKIM passes. (senders.yahooinc.com)

The most common email authentication failures—and how to fix them

“SPF pass, DMARC fail”

This almost always indicates an alignment problem. The envelope sender authenticated successfully, but its domain differs from the visible From domain. Configure a custom return-path or envelope-sender domain under your domain, or ensure DKIM signs with an aligned domain.

“DKIM pass, DMARC fail”

Check the header.d= value. A provider may be signing correctly with its own domain rather than yours. Enable the provider’s custom DKIM or domain-authentication feature, publish the associated DNS records, and test again.

“No DMARC record found”

The record may be at the wrong hostname. It belongs at _dmarc.example.com, not example.com and not dmarc.example.com. Also verify that it is a TXT record and that another conflicting DMARC record has not been created.

“SPF permerror”

Common causes include two SPF TXT records, invalid syntax, or too many DNS lookups. Merge valid policies into a single SPF record, remove obsolete provider includes, and redesign streams that make the lookup tree too deep.

“Legitimate forwarded mail fails”

Forwarders often break SPF because the forwarding IP is not authorized by the original envelope domain. Mailing lists and gateways can also alter content that DKIM signed. Maintain aligned DKIM for your own outbound mail, test high-value indirect flows, and recognize that receiving systems can make local exceptions for forwarded mail. Gmail documents that DMARC alignment is not required for forwarded or mailing-list messages in its bulk-sender requirements. (support.google.com)

“We set p=reject and mail disappeared”

Roll back to p=none or a safer policy while you investigate reports and message headers. Identify every legitimate source before returning to enforcement. The right answer is not to permanently disable DMARC; it is to authenticate and align the forgotten sender.

Related controls: important, but not substitutes for SPF, DKIM, and DMARC

Several adjacent technologies improve email security or presentation but solve different problems.

MTA-STS lets a recipient domain publish a policy requiring SMTP senders to use authenticated TLS when delivering mail to that domain. It protects transport to your inbound mail infrastructure; it does not establish that an outbound message’s From domain is legitimate. SMTP TLS Reporting provides reports about failures involving MTA-STS or DANE transport policies. (rfc-editor.org)

ARC (Authenticated Received Chain) helps preserve authentication assessments through intermediaries that modify messages. It is particularly relevant to forwarding and mailing-list flows, but it does not replace publishing aligned SPF, DKIM, and DMARC for the original sender. (dmarc.org)

BIMI can display a verified brand indicator in supporting inboxes when additional requirements are met. It is a brand-presentation layer, not a baseline authentication method. Get DMARC enforcement correct before considering it.

Reverse DNS, TLS, and unsubscribe headers are separate sender requirements that may affect delivery. For example, Gmail’s sender guidelines require valid forward and reverse DNS and TLS, and high-volume promotional senders have additional unsubscribe obligations. Fixing SPF, DKIM, and DMARC does not eliminate those responsibilities. (support.google.com)

A durable operating model for authenticated email

Authentication should be part of vendor onboarding and change management, not a one-time DNS project. Any team that adds a system capable of sending email should answer four questions before launch:

1. Which From domain will recipients see?
2. Which envelope domain will the system use?
3. Which DKIM domain and selector will sign mail?
4. How will the team test DMARC alignment and monitor failures after release?

Keep a current sender inventory, give DNS access and mail-platform access to accountable owners, and rotate DKIM keys according to your provider’s supported process. When retiring a vendor, remove its signing authorization only after you have stopped the traffic and confirmed it no longer appears in reports.

The practical standard is simple: every legitimate mail stream should produce an aligned SPF or DKIM pass for its visible From domain, and your DMARC policy should progressively prevent everyone else from using that domain. That is how email authentication methods become both a deliverability foundation and a meaningful anti-spoofing control.

FAQ

What are the three main email authentication methods?

The core sender-authentication stack is SPF, DKIM, and DMARC. SPF authorizes sending servers, DKIM signs mail with a domain-associated key, and DMARC requires aligned SPF or DKIM for the visible From domain while publishing a failure policy and reporting destination.

Do I need SPF, DKIM, and DMARC, or is one enough?

Use all three. DMARC depends on SPF and/or DKIM, and each underlying method has different failure modes. DKIM can survive many forwarding scenarios that break SPF, while SPF can still provide a second aligned path when DKIM fails.

Does DMARC require both SPF and DKIM to pass?

No. DMARC passes when either SPF passes and aligns with the From domain, or DKIM passes and aligns with the From domain. Operating both is still the recommended design because it provides redundancy.

Should I start DMARC with p=reject?

Usually no. Start with p=none, review aggregate reports and real message headers, authenticate every approved sender, then move through quarantine to reject when legitimate traffic is consistently aligned.

Can email authentication stop all phishing?

No. It is highly effective against direct impersonation of domains you protect, but it cannot stop attackers from using lookalike domains, compromised legitimate accounts, or unrelated domains. Combine it with user education, account security, monitoring, and careful handling of suspicious mail.