Email Authentication Settings: Configure SPF, DKIM, and DMARC Correctly

Email authentication settings are the DNS records and sending-platform controls that prove your mail is authorized to use your domain. The practical goal is straightforward: every legitimate system that sends as your domain should pass SPF and/or DKIM, and at least one passing identifier should align with the address people see in the From: field.

For most organizations, that means configuring three related standards: SPF, DKIM, and DMARC. They are not interchangeable checkboxes. SPF names permitted senders, DKIM cryptographically signs messages, and DMARC connects those results to the visible From: domain while telling receiving providers how to handle failures. DMARC also enables aggregate reporting so you can discover unknown senders and spoofing attempts. (rfc-editor.org)

What email authentication settings actually do

Email was designed so that several identities can appear in one message. The envelope sender used during SMTP delivery, the domain used to sign DKIM, and the visible From: address can all be different. That flexibility supports legitimate workflows, but it also makes impersonation possible unless recipients can validate the relationships.

Email authentication settings let the owner of a domain publish information in DNS that recipients can check. They help a recipient decide whether a sending service is authorized, whether the message was altered after signing, and whether the validated domain belongs to—or is aligned with—the domain shown to the recipient. (rfc-editor.org)

Authentication is important for security and delivery, but it is not a magic inbox-placement guarantee. A passing message can still be filtered because of recipient complaints, poor engagement, malicious content, unsafe links, a new sending pattern, or other reputation signals. Conversely, SPF alone does not stop all spoofing because it validates the envelope identity rather than the visible author domain. (learn.microsoft.com)

The three records you need to understand

The safest baseline is not “pick one.” Configure all three. Google’s sender rules require every sender to have SPF or DKIM, while bulk senders to personal Gmail accounts must use SPF, DKIM, and DMARC. Google defines a bulk sender as one that sends close to 5,000 or more messages to personal Gmail accounts in a 24-hour period, and the classification does not expire after it is assigned. (support.google.com)

Inventory every system that sends as your domain

The hardest part of email authentication settings is usually not writing DNS syntax. It is finding every legitimate source of mail before you publish a restrictive DMARC policy.

Start with the domain in the visible From: address, not just the mailbox provider. If your people send from name@example.com, your website sends password resets from support@example.com, and your marketing platform sends newsletters from news@example.com, each workflow must be accounted for.

Build a sender inventory before changing DNS

Make a small table with one row per sender:

Do not assume an application is covered simply because it can send mail using a company mailbox. A contact form, ecommerce platform, CRM, invoice tool, recruiting suite, status-page service, and support platform can each create a separate authenticated mail flow.

Also list subdomains separately. example.com, mail.example.com, and news.example.com can have different SPF, DKIM, and DMARC behavior. A subdomain can be useful for separating product or marketing mail from employee mail, but it is not a substitute for authenticating the parent domain.

Find senders you forgot about

Use more than one source of truth:

1. Review DNS records, especially existing SPF include: mechanisms and DKIM selectors.
2. Search application settings for “domain authentication,” “sending domain,” “return-path,” “custom MAIL FROM,” “DKIM,” or “sender verification.”
3. Review invoices and SSO app catalogs for email, CRM, support, commerce, survey, and HR tools.
4. Inspect headers from a sample message from every workflow.
5. Start DMARC reporting in monitor mode and compare observed senders against your inventory.

DMARC aggregate reports expose SPF and DKIM evaluation outcomes, applied policy, and source information. They are designed to give a domain owner visibility into the systems using its domain. (rfc-editor.org)

Configure SPF without creating a fragile record

Sender Policy Framework (SPF) is a TXT record that tells receivers which servers or services may send mail using a domain in the SMTP envelope sender, commonly shown in message details as Return-Path or MAIL FROM.

A basic SPF record looks like this:

Host:  @
Type:  TXT
Value: v=spf1 include:_spf.google.com ~all

That is an example for a domain whose only outbound sender is Google Workspace. The exact value is provider-specific. Microsoft 365, Amazon SES, an email API provider, and marketing tools each publish their own current authentication instructions. Use the value supplied by the vendor for your account and region rather than copying an example intended for a different service.

SPF syntax that matters

An SPF record begins with v=spf1, followed by mechanisms that authorize senders, and ends with an all mechanism:

v=spf1 include:provider-one.example include:provider-two.example ~all

Common pieces include:

• include:domain — delegates authorization checks to another domain’s SPF record.
• ip4:203.0.113.25 — authorizes a specific IPv4 address. Use only when you control and can maintain that address.
• ip6:2001:db8::/32 — authorizes an IPv6 address or range.
• a or mx — authorizes addresses resolved from A/AAAA or MX records. These can be harder to reason about as infrastructure changes.
• ~all — a soft failure for sources not authorized by the record.
• -all — a hard failure for sources not authorized by the record.

A strict ending does not compensate for a missing sender. If you use -all before every real system is covered, legitimate mail can fail SPF. The appropriate ending depends on your deployment state, but the important rule is to authorize real senders accurately and rely on aligned DKIM as a durable second path to DMARC pass.

One domain must publish one SPF policy

A common mistake is adding a second TXT record because a new vendor says “add this SPF record.” SPF does not work as a collection of independent records. Combine authorized services into one SPF TXT value for the same domain.

Incorrect:

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

Correct, assuming those are the only authorized senders and the vendor’s documented include is accurate:

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

Google explicitly advises updating SPF when you begin using a new mail server or third-party sender, after identifying all senders for the domain. (support.google.com)

Respect SPF’s DNS lookup limit

SPF evaluation has a hard limit of 10 DNS-querying terms. Includes, redirects, a, mx, exists, and ptr can consume that budget directly or indirectly. Exceeding the limit produces a permanent SPF error (permerror), which can contribute to delivery and DMARC problems. (rfc-editor.org)

This is why “just add another include” eventually becomes dangerous. If your root-domain SPF is already complex, use these options:

• Stop routing every vendor through root-domain SPF when the service can use a dedicated custom return-path subdomain.
• Prefer DKIM alignment for vendors that support domain signing.
• Remove retired vendors and stale IP ranges.
• Consolidate only with a maintained SPF-flattening process if you fully understand the operational trade-offs; flattening needs monitoring because vendor IP ranges can change.

Do not publish obsolete SPF record type SPF. Publish SPF version 1 policy in a DNS TXT record, as current provider documentation directs. (support.google.com)

Configure DKIM for every sending platform

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to outgoing mail. The sending system holds the private key; recipients retrieve the public key from DNS and use it to validate the DKIM-Signature header.

The signing domain is visible in the signature’s d= tag, and the selector is visible in s=. Together, they tell the recipient where to look up the public key:

selector._domainkey.example.com

DKIM verifies that the signed portions of a message were not changed after signing. It can sign headers and the body, and one message can carry multiple DKIM signatures. (learn.microsoft.com)

TXT versus CNAME DKIM records

Your provider normally gives you one of two patterns:

A TXT public key record

Host:  selector1._domainkey
Type:  TXT
Value: v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_FROM_YOUR_PROVIDER

A CNAME delegation record

Host:  selector1._domainkey
Type:  CNAME
Value: selector1-example-com._domainkey.provider.example

Do not invent the selector, destination, or public key. Copy the exact host and value shown in your sending provider’s domain-authentication screen. Some products use CNAME records so they can rotate keys without making you edit the key itself; Microsoft 365, for example, documents CNAME records for DKIM, while other systems can use TXT records. (learn.microsoft.com)

DKIM configuration checklist

For each mail system:

1. Add and verify the domain inside the provider’s dashboard or API configuration.
2. Publish every DKIM DNS record the provider supplies. Some providers issue two or three CNAME records.
3. Wait for DNS visibility, then activate DKIM signing in the provider if activation is a separate step.
4. Send a real message to a test mailbox.
5. Confirm the message has dkim=pass and that the d= domain aligns with the visible From: domain.
6. Keep the DNS record in place when rotating keys until the provider confirms old selectors are no longer used.

A frequent failure is stopping at “domain verified.” Domain ownership verification and DKIM signing are related but separate controls in many systems. Another is accepting a provider signature such as d=provider.example when your DMARC policy needs a signature aligned with example.com. A vendor signature can be technically valid while still failing DMARC alignment.

Set DMARC to connect SPF, DKIM, and your From address

DMARC is the policy layer. It checks whether SPF or DKIM passed and whether the domain that passed is aligned with the domain in the visible RFC 5322 From: header.

A message passes DMARC when either of these conditions is true:

• SPF passes and the SPF-authenticated envelope-sender domain aligns with the visible From: domain.
• DKIM passes and the DKIM signing domain (d=) aligns with the visible From: domain.

Both do not need to pass, though configuring both is strongly preferable. If neither aligned path passes, DMARC fails. (rfc-editor.org)

The core DMARC record

Publish DMARC as a TXT record at _dmarc:

Host:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Replace example.com with a mailbox or reporting endpoint you control. The record says:

• v=DMARC1 — declares DMARC.
• p=none — asks receivers to monitor; it does not request quarantine or rejection.
• rua=mailto: — requests aggregate reports at the specified destination.
• adkim=r — relaxed DKIM alignment.
• aspf=r — relaxed SPF alignment.

Relaxed alignment generally permits a subdomain relationship, such as a DKIM signature from mail.example.com for a message visibly sent from example.com. Strict alignment requires an exact domain match. DMARC supports relaxed and strict alignment modes. (rfc-editor.org)

Choose DMARC policy in stages

Do not start with p=reject solely because it is the strongest policy. Start by observing real traffic.

A practical rollout looks like this:

1. Monitor: p=none with an rua address. Identify every authorized and unauthorized source.
2. Fix: Configure aligned DKIM and/or aligned SPF for legitimate systems that fail.
3. Quarantine: Change to p=quarantine once reporting shows coverage is reliable. This asks receivers to treat failing mail as suspicious.
4. Reject: Change to p=reject when you are confident that mail failing DMARC is not legitimate mail you need delivered.

DMARC policy options include delivery with no requested action, quarantine, and reject. Receiving systems ultimately make their own handling decisions, so a policy is a strong instruction rather than an absolute command. (support.google.com)

DMARC reports are operational data, not a mailbox task

Aggregate reports are usually XML attachments and can become numerous. Google notes that large organizations can receive hundreds or thousands daily and recommends a dedicated mailbox or group for reports. (support.google.com)

For a small domain, a dedicated mailbox and a report-parsing tool may be enough. For a larger organization, route reports to a purpose-built DMARC analysis service or internal pipeline. Your review process should answer four questions:

• Which IPs and vendors are sending as the domain?
• Which messages pass SPF, DKIM, and DMARC?
• Which legitimate systems fail because of missing alignment or broken DNS?
• Are unauthorized systems attempting to impersonate the domain?

If the rua address is outside the domain publishing DMARC, the external reporting domain may need an authorization DNS record. Keep reports in the same domain unless you understand and configure the external-destination requirement. (support.google.com)

Worked example: authenticate a small business domain

Assume northstarstudio.example uses Google Workspace for employee mail and an email API provider for product notifications. The company wants messages sent from hello@northstarstudio.example and updates@northstarstudio.example to authenticate while it gathers DMARC data.

Step 1: Start with the known sender

Google Workspace is the only existing sender. The root SPF record is:

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

This is appropriate only if Google Workspace is genuinely the only authorized root-domain envelope sender. The company confirms there is no second SPF TXT record.

Step 2: Enable Google Workspace DKIM

In Google Workspace, the administrator generates a DKIM key and receives the DNS hostname and public-key value. The format will resemble:

Host:  google._domainkey
Type:  TXT
Value: v=DKIM1; k=rsa; p=[public key generated by Google Workspace]

The administrator publishes the exact generated value, returns to Google Workspace, and turns DKIM signing on after the provider sees the DNS record. Google documents this flow as generating a key pair, adding the public key to DNS, then turning on and verifying DKIM. (support.google.com)

Step 3: Authenticate the product-email provider

The engineering team opens the provider’s domain-authentication page and adds the supplied DKIM CNAME or TXT records. If the provider asks for a custom bounce or MAIL FROM subdomain, the team uses a dedicated domain such as bounce.northstarstudio.example and publishes the provider’s required MX and SPF entries there.

This separation matters. A custom MAIL FROM domain lets an email service use SPF on a subdomain you control, but it may require both an MX record and an SPF record. Amazon SES, for example, requires MX and SPF records for a custom MAIL FROM domain. (docs.aws.amazon.com)

The provider must also sign using northstarstudio.example or an aligned subdomain such as mail.northstarstudio.example. A generic provider DKIM signature that uses only the vendor’s domain is not enough for aligned DKIM.

Step 4: Avoid blindly expanding root SPF

If the product provider uses its own custom MAIL FROM subdomain and aligned DKIM, the root SPF record may not need another include. If it instead sends using northstarstudio.example as the envelope-sender domain, the team must merge the vendor’s documented SPF mechanism into the one existing root SPF record.

The team does not create a second root SPF TXT record. It also checks the combined policy’s lookup count before publishing it.

Step 5: Publish DMARC in monitor mode

The initial record is:

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

The team creates dmarc-reports@northstarstudio.example as a monitored mailbox or group. It sends test messages from Google Workspace and the product application, then waits for aggregate reports and checks their message headers.

Step 6: Verify results from actual messages

In the delivered message’s original headers, the team looks for a line similar to:

Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass

The exact formatting differs by mailbox provider. In Microsoft 365, received messages include an Authentication-Results header showing SPF, DKIM, DMARC, and other authentication results. (learn.microsoft.com)

For the product messages, the team specifically verifies that dmarc=pass is based on an aligned SPF or DKIM identifier. A generic dkim=pass alone is not the finish line.

Step 7: Enforce only after coverage is proven

After the reports show that employee mail and product mail reliably pass DMARC—and no other approved sender is failing—the company can move to:

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

Later, after continued review, it can use:

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

This staged approach protects against breaking a forgotten invoice tool, CRM workflow, or support platform while steadily reducing the chance that unauthenticated impersonation mail is accepted.

Test email authentication settings the right way

DNS lookup tools are necessary but not sufficient. They show that a record is published; they do not prove your live sending system uses it correctly.

Use a three-layer verification process.

1. Check published DNS

Confirm that each record exists at the correct hostname:

dig TXT example.com +short
dig TXT selector._domainkey.example.com +short
dig TXT _dmarc.example.com +short

Replace selector with the real selector supplied by the provider. If your DNS dashboard automatically appends the domain, enter only the relative host label such as _dmarc or selector._domainkey; if it requires fully qualified names, use the full hostname. DNS interfaces differ, so always inspect the saved record name after publishing.

2. Send a production-like test message

Send from every system—not just a desktop mail client—to a mailbox where you can view full headers. Test different From addresses, transactional templates, marketing templates, and reply paths if they differ.

Check for:

• spf=pass or a known reason SPF does not pass.
• dkim=pass for a signature using your domain or an aligned subdomain.
• dmarc=pass.
• A visible From: address matching the intended brand domain.
• A return-path or envelope-sender domain that makes sense for the mail flow.

3. Review DMARC reports and provider dashboards

A single test proves one path. Aggregate reports help reveal paths that run only on schedules, after a purchase, from a specific region, or from an overlooked business tool. Bulk senders to Gmail can also use Postmaster Tools’ compliance and diagnostic information where available. (support.google.com)

If you are still debugging the ability to reach an address at all, use an email address verification tool before treating a non-delivery as an SPF, DKIM, or DMARC failure.

Common email authentication settings mistakes and fixes

Duplicate SPF records

Symptom: SPF returns permerror, or authentication tools report multiple SPF records.

Fix: Merge all approved mechanisms into one v=spf1 TXT record for that domain. Recalculate lookup count after merging.

SPF passes but DMARC fails

Symptom: Header shows spf=pass and dmarc=fail.

Cause: SPF may be passing for a vendor or bounce domain that does not align with the visible From: domain.

Fix: Configure a custom aligned MAIL FROM domain where supported, or ensure the provider signs DKIM with your domain or aligned subdomain. DMARC requires both a passing SPF or DKIM result and alignment. (rfc-editor.org)

DKIM passes but DMARC fails

Symptom: dkim=pass, yet dmarc=fail.

Cause: The signature is from the provider’s domain, not yours, or the displayed From domain differs from the domain you authenticated.

Fix: Complete the provider’s custom-domain DKIM setup and inspect the d= value in the DKIM signature after sending.

DKIM DNS exists, but no messages are signed

Symptom: A DKIM record resolves, but sent messages have no signature for your domain.

Fix: Return to the sender’s dashboard. Some products require a separate enablement step after DNS verification. Confirm the correct sending domain is selected for the specific mail stream.

DMARC rejects legitimate mail after enforcement

Symptom: A SaaS platform’s mail begins landing in spam or being rejected after p=quarantine or p=reject.

Fix: Temporarily diagnose rather than weakening every control. Find the source in DMARC reports, configure vendor DKIM and alignment, then retest. If the workflow cannot authenticate as your domain, consider a clearly separated sender domain or change the workflow.

Forwarded messages fail SPF

Symptom: Mail works directly but SPF fails after forwarding.

Cause: SPF checks the connecting server. A forwarder is not normally included in the original sender’s SPF record.

Fix: This is expected behavior; aligned DKIM is especially important because it can survive forwarding when the signed content is preserved. Microsoft documents forwarded-message SPF failure as expected when the forwarding IP is absent from the original SPF policy. (learn.microsoft.com)

Publishing DMARC at the wrong hostname

Symptom: Validation tools cannot find DMARC, even though a TXT value appears in DNS.

Fix: The record belongs at _dmarc.example.com, not at the root example.com and not at dmarc.example.com unless your DNS interface constructs the name differently.

Operational practices that keep authentication working

Email authentication is not a one-time migration. It should be part of your sender-change process.

Treat a new sending vendor as a DNS and deliverability change

Before a team turns on a new CRM, marketing platform, or email API, require answers to these questions:

1. Which domain will appear in From:?
2. What DKIM records does the vendor require?
3. Can it sign with our domain or an aligned subdomain?
4. Does it need a custom bounce, return-path, or MAIL FROM domain?
5. Does it require an SPF include, and what is the resulting lookup count?
6. Who will verify live headers and DMARC reports after launch?

For teams sending application email programmatically, keep authentication steps beside the sending integration rather than in a forgotten registrar account. Your email API setup guides should document domain verification, DKIM activation, sender ownership, and test-message checks as deployment requirements.

Rotate keys and remove obsolete DNS safely

DKIM key rotation reduces the impact of a compromised or aging key, but rotation can break mail if an old selector is removed while a sender is still using it. Add the new record, switch signing, verify headers, and only then retire the old selector according to the provider’s guidance.

Use modern vendor defaults where possible. DKIM standards support RSA keys and also define Ed25519-SHA256; the relevant RFC updates DKIM with Ed25519 public keys stored in DNS. Your email platform determines which algorithms and record formats it supports, so follow its documented configuration rather than forcing a key type. (rfc-editor.org)

Monitor the things DNS checks cannot show

A valid DNS record is only a control-plane check. Monitor real delivery outcomes as well:

• DMARC pass rate by source.
• New sources appearing in aggregate reports.
• SPF permanent errors and lookup-budget changes.
• DKIM signature failures after provider or template changes.
• Delivery errors, complaint signals, and spam-folder placement.
• Unauthorized use of your domain in DMARC reports.

The best outcome is not merely a green “DNS verified” badge. It is a stable state where every approved mail source has an aligned authentication path, unapproved mail is visible, and DMARC enforcement can be used without breaking business mail.

FAQ

What are the minimum email authentication settings?

At minimum, configure SPF or DKIM for every domain that sends email. In practice, configure SPF, DKIM, and DMARC together: SPF authorizes senders, DKIM signs mail, and DMARC validates aligned identity and publishes handling policy. Google requires SPF or DKIM for all senders to personal Gmail accounts and SPF, DKIM, and DMARC for bulk senders. (support.google.com)

Does SPF need to pass for DMARC to pass?

No. DMARC passes if either SPF passes and aligns with the visible From domain, or DKIM passes and aligns with that domain. That is why aligned DKIM is critical for modern multi-vendor email programs. (learn.microsoft.com)

Should I use p=none, p=quarantine, or p=reject?

Begin with p=none to collect reports and identify all legitimate sending systems. Move to p=quarantine after correcting failures, then consider p=reject when reporting shows reliable coverage. Never enforce based only on a single successful test email.

Why does my email show DKIM pass but DMARC fail?

The DKIM signature may belong to your provider rather than your domain. Inspect the d= value in the DKIM signature. For DMARC, the signing domain must align with the domain in the visible From: address.

How long do DNS changes take to work?

DNS visibility depends on your DNS provider’s TTL settings, resolver caches, and the sending platform’s verification process. Publish records first, confirm them with DNS lookups, wait for the provider to verify them, and then validate live message headers. Do not change DMARC to enforcement until reports confirm the real mail flows are covered.