SPF, DKIM & DMARC Setup: Email Authentication and Deliverability Guide

Mailbox-provider requirements can narrow or add to the base protocol, so standards compliance and Gmail/Yahoo delivery requirements should be checked separately.

19. DMARC Record Location

DMARC is published under:

_dmarc.example.com

20. Start with a Monitoring Policy

A basic monitoring-stage record can look conceptually like:

v=DMARC1; p=none; rua=mailto:[email protected]

Use a mailbox or reporting service capable of handling DMARC aggregate reports.

21. What p=none Means

p=none is commonly used for monitoring.

It lets domain owners collect authentication information without requesting quarantine or rejection solely from the DMARC policy.

It is not the same as having no DMARC record.

Aggregate reporting with rua

The rua= tag specifies where DMARC aggregate XML reports should be sent. Aggregate reports are useful for identifying sending sources, SPF/DKIM results and alignment patterns before stricter enforcement.

Forensic/failure reporting with ruf

The ruf= tag can request message-specific DMARC failure reports, but not every receiver sends them. They can expose message-related metadata or content depending on implementation, so use them only when you understand receiver support, privacy, retention and access controls.

22. DMARC Quarantine

A stricter policy can request quarantine handling for messages that fail DMARC:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Do not move to quarantine before authenticating legitimate senders.

23. DMARC Reject

A stronger enforcement policy can request rejection:

v=DMARC1; p=reject; rua=mailto:[email protected]

24. DMARC Alignment

Authentication alone is not enough for DMARC.

The authenticated domain must align with the visible From domain.

For example:

Visible From:
[email protected]

DKIM signing domain:
example.com

Result:
Potential DKIM alignment

25. SPF Alignment

SPF can contribute to DMARC when the authenticated envelope domain aligns with the From domain.

A message can therefore:

• Pass SPF but fail DMARC because of misalignment.
• Fail SPF but still pass DMARC through aligned DKIM.

26. DKIM Alignment

DKIM can contribute to DMARC when the signing domain aligns with the visible From domain.

This often makes properly configured DKIM especially valuable in environments where mail is forwarded.

27. Relaxed vs Strict Alignment

DMARC supports relaxed and strict domain alignment modes.

Relaxed alignment can permit organizational-domain relationships between subdomains and the parent domain.

Strict alignment requires a closer domain match.

Do not enable strict modes without understanding every sender and subdomain involved.

28. Third-Party Email Platforms

A domain may legitimately send mail through:

• Google Workspace.
• Microsoft 365.
• Helpdesk software.
• CRM systems.
• Newsletter platforms.
• Transactional email services.
• WordPress SMTP providers.

Each sender needs the appropriate authentication configuration.

29. Create a Sender Inventory

Before changing DMARC enforcement, document:

30. WordPress Email

WordPress websites can send:

• Password-reset messages.
• Contact-form notifications.
• WooCommerce orders.
• Membership notifications.

Do not assume the web server's default PHP mail transport is the best production mail architecture.

31. Use an Authenticated Mail Provider for Important Transactional Mail

For critical application mail, a dedicated SMTP or transactional-email provider can offer:

• Authenticated sending.
• DKIM support.
• Bounce handling.
• Delivery logs.

This does not eliminate the need to configure your domain's DNS correctly.

32. Sending from a VPS Requires More Than SPF

If you operate your own mail server, you may also need:

• Forward DNS.
• Reverse DNS / PTR.
• TLS.
• Correct HELO/EHLO identity.
• IP reputation.
• Queue management.
• Bounce processing.

Self-hosting a web server does not mean you should automatically self-host outbound email.

33. PTR / Reverse DNS

Mailbox providers can evaluate whether a sending IP has valid reverse DNS and whether the corresponding hostname resolves back appropriately.

PTR records are normally configured by the IP or hosting provider, not through an ordinary website DNS TXT record.

34. SPF, DKIM and DMARC Do Not Replace PTR

Email infrastructure is layered.

You may need:

Forward DNS
+
Reverse DNS
+
TLS
+
SPF
+
DKIM
+
DMARC
+
Good Sending Practices

35. DNS TTL During Authentication Changes

DNS changes do not appear everywhere instantaneously.

When planning a migration, lower TTL in advance where appropriate, make the change, verify it, and restore a normal stable TTL afterward.

For DNS fundamentals, continue with our DNS Configuration Best Practices.

36. Do Not Delete Existing TXT Records Blindly

A domain can have several TXT records serving different purposes.

Examples include:

• SPF.
• DKIM.
• Site verification.
• Service ownership verification.

Deleting unrelated TXT records can break other services.

37. Verify the Hostname Field in Your DNS Panel

DNS providers present record names differently.

For a DKIM hostname such as:

selector1._domainkey.example.com

one panel may expect:

selector1._domainkey

while another interface may display the full hostname.

Confirm that the final DNS name is correct after saving.

38. Common SPF Failure: Missing Third-Party Sender

Example:

Business email provider → authorized

Newsletter platform → forgotten

Result:
Newsletter SPF may fail

39. Common DKIM Failure: Wrong Selector

If the sender signs using one selector but DNS contains a key under another selector, the receiver cannot retrieve the expected public key.

Check the message's DKIM signature and compare its selector with DNS.

40. Common DKIM Failure: Modified Message

Mail gateways, forwarding systems, or security tools can sometimes modify signed portions of a message.

Depending on what was signed and modified, the DKIM signature can fail verification.

41. Common DMARC Failure: Authentication Passes but Alignment Does Not

For example:

Visible From:
[email protected]

DKIM signs:
mailer.vendor-example.net

SPF authenticates:
bounce.vendor-example.net

Result:
Authentication may pass,
but DMARC alignment can fail.

The email provider should normally offer a custom-domain authentication configuration to solve this.

42. DMARC Aggregate Reports

Aggregate reports can help identify:

• Sending IPs.
• SPF results.
• DKIM results.
• Alignment.
• Potential unauthorized sources.

They are especially useful before increasing enforcement.

External rua/ruf destinations need authorization

If the reporting mailbox is outside the domain publishing the DMARC policy, current DMARC reporting rules require additional DNS authorization at the report-consumer domain for conforming receivers to send reports there.

Conceptually, if example.com requests reports at [email protected], the report consumer publishes an authorization TXT record under a name shaped like:

example.com._report._dmarc.thirdparty.example.net
TXT "v=DMARC1;"

Use the exact hostname required by the reporting provider rather than copying this example literally.

43. Use a Dedicated DMARC Reporting Address

DMARC XML reports can be machine-oriented and numerous.

A dedicated address or reporting service can keep them separate from normal business email.

44. Do Not Jump from No DMARC to Reject Without Observation

A safer operational progression is:

Inventory senders
      ↓
Configure SPF + DKIM
      ↓
DMARC p=none
      ↓
Review reports
      ↓
Fix alignment
      ↓
Gradual enforcement
      ↓
Quarantine / Reject if appropriate

45. Subdomains

Large organizations may send different types of mail from separate subdomains.

For example:

example.com
mail.example.com
news.example.com
transactional.example.com

This can separate sending streams and authentication configurations, but it also increases DNS and operational complexity.

Use sp= and np= deliberately

DMARC supports sp= for existing subdomains of the organizational domain. RFC 9989 also defines np= for non-existent subdomains. If np is absent, the applicable sp or parent p policy is used. Do not add strict subdomain policy until legitimate subdomain senders are inventoried.

46. Marketing and Transactional Mail Should Be Treated Differently

Marketing and transactional email have different user expectations and operational characteristics.

Keeping them logically separated can make:

• Reputation monitoring.
• Authentication.
• Complaint analysis.
• Operational troubleshooting.

easier.

47. Authentication Does Not Guarantee Inbox Placement

A message can pass SPF, DKIM, and DMARC and still be:

• Delivered to spam.
• Rate limited.
• Rejected for another reason.

Authentication is one important part of the sender-quality system.

48. Spam Complaint Rates Matter

Mailbox providers evaluate whether recipients actually want the messages they receive.

Do not treat technical authentication as permission to send unsolicited bulk email.

Use:

• Clear opt-in practices.
• Relevant content.
• Functional unsubscribe mechanisms where required.
• Reasonable sending volume.

49. Current Gmail and Yahoo Sender Requirements

Mailbox-provider rules change, so verify their official sender documentation regularly. As of September 25, 2026, the following requirements are current for mail sent to Gmail and Yahoo users.

Gmail

• All senders to personal Gmail accounts must use SPF or DKIM.
• Senders sending about 5,000 or more messages per day to personal Gmail accounts are treated as bulk senders; Google counts traffic across the same primary domain.
• Bulk senders must use both SPF and DKIM and publish DMARC; p=none is permitted as the minimum DMARC policy.
• For direct mail, the visible From domain must align with either the SPF organizational domain or DKIM organizational domain.
• Google requires valid forward and reverse DNS, TLS and RFC-compliant message formatting.
• Marketing and promotional messages from bulk senders must support one-click unsubscribe and include a visible unsubscribe link.
• Google says senders should keep user-reported spam below 0.1% and prevent it from reaching 0.3% or higher.
• Google's current FAQ says bulk-sender classification does not expire once assigned.
• Google is actively enforcing the requirements; non-compliant traffic can experience spam placement, temporary failures or permanent rejections depending on the issue.

See Google’s current email sender guidelines and sender FAQ.

Yahoo

• All senders must authenticate with SPF or DKIM at minimum.
• Bulk senders must use both SPF and DKIM and publish a valid DMARC policy with at least p=none.
• For DMARC, the From domain must align with either the SPF or DKIM domain; relaxed alignment is acceptable.
• Yahoo requires valid forward and reverse DNS for sending IPs and RFC-compliant messages.
• Marketing/subscription mail must provide easy unsubscribe support.
• Yahoo instructs senders to keep spam complaint rates below 0.3%.

Yahoo does not publish a fixed numerical bulk-sender threshold in its current FAQ. See the current Yahoo Sender Requirements.

These are provider-specific operational requirements, not a universal legal standard for all email systems.

50. TLS and Email Authentication Solve Different Problems

TLS protects mail while it is transmitted between compatible mail systems.

SPF, DKIM, and DMARC authenticate domain identity and policy.

You generally need both transport security and authentication.

51. Verify DNS Before Reading Message Headers

Confirm what public DNS actually returns after saving records:

# SPF
dig +short TXT example.com

# DKIM
dig +short TXT selector1._domainkey.example.com

# DMARC
dig +short TXT _dmarc.example.com

If your DNS panel automatically appends the zone name, verify the final public hostname instead of trusting only how the control panel displays the host field.

52. Diagnose Using Message Headers

When mail reaches a test mailbox, inspect the authentication results in the message headers.

Look for results such as:

spf=pass
dkim=pass
dmarc=pass

Then confirm which domains actually authenticated and aligned.

53. Test Each Sending System Separately

Do not test only your normal mailbox and assume every platform is authenticated.

Send test messages independently from:

• Website contact form.
• WooCommerce.
• Newsletter provider.
• CRM.
• Support desk.
• Business mailbox.

54. Email Authentication Deployment Workflow

1. Inventory every legitimate sender.
2. Review existing DNS TXT records.
3. Create one valid SPF policy covering legitimate senders.
4. Enable DKIM for each sending platform.
5. Verify SPF and DKIM using real test messages.
6. Publish DMARC with monitoring/reporting.
7. Review aggregate reports.
8. Fix unknown or misaligned senders.
9. Verify PTR and TLS where relevant.
10. Gradually increase DMARC enforcement when appropriate.
11. Continue monitoring after changes.

55. Related DNS and Email Infrastructure Path

This guide belongs within the DNS and infrastructure cluster:

DNS Configuration
      ↓
SPF / DKIM / DMARC
      ↓
Email Infrastructure
      ↓
Hosting / VPS Architecture

This is an infrastructure and authentication topic. It does not need unrelated VPN, themes, B2B prospecting, package forwarding, or general SaaS affiliate links.

Summary: SPF, DKIM & DMARC Checklist

• Inventory every platform sending mail for your domain.
• Publish only one valid SPF policy per domain.
• Include every legitimate SPF sender.
• Watch SPF DNS lookup complexity.
• Enable DKIM for every supported sender.
• Protect DKIM private keys.
• Use modern key lengths supported by your provider.
• Rotate DKIM selectors when appropriate.
• Understand DMARC alignment.
• Start DMARC with monitoring rather than blind enforcement.
• Review aggregate reports.
• Correct unauthorized and misaligned senders.
• Use quarantine/reject only after validation.
• Verify forward and reverse DNS on self-managed mail infrastructure.
• Use TLS.
• Test every sending platform independently.
• Inspect real message authentication headers.
• Do not claim authentication guarantees inbox placement.
• Monitor current mailbox-provider requirements for bulk sending.

Frequently Asked Questions

Do I need SPF, DKIM and DMARC?

For a production domain, configuring all three is a strong baseline. Some mailbox providers require different minimum combinations depending on sending volume, so check their current sender requirements as well.

What is the SPF 10-lookup limit?

RFC 7208 limits SPF evaluation to 10 DNS-querying terms such as include, a, mx, ptr, exists and redirect. Exceeding the limit causes SPF permerror.

What does DMARC alignment mean?

DMARC alignment means the domain authenticated by SPF or DKIM has the required relationship with the domain users see in the From header. A message can pass SPF or DKIM authentication and still fail DMARC if the authenticated domain does not align.

Does SPF prevent email spoofing?

SPF helps receivers evaluate whether the envelope sender used authorized infrastructure, but SPF alone does not fully protect the visible From address. DMARC adds domain-alignment checks and policy.

Can I have two SPF records?

You should not publish multiple independent SPF policies for the same domain. Legitimate sending sources generally need to be represented within one valid SPF record.

What is a DKIM selector?

A selector identifies which DKIM public key a receiver should retrieve from DNS. It allows multiple keys and makes key rotation possible.

Should I use DMARC p=reject immediately?

Usually not on an existing production domain unless every legitimate sender has already been audited and authenticated. Start with monitoring, review reports, fix alignment, and move toward enforcement carefully.

Can SPF pass while DMARC fails?

Yes. SPF can authenticate successfully while the authenticated domain does not align with the visible From domain, causing SPF not to satisfy DMARC.

Can email pass DMARC if SPF fails?

Yes. An aligned DKIM signature can satisfy DMARC even when SPF fails.

Do SPF, DKIM and DMARC guarantee email delivery?

No. They strengthen authentication and domain protection, but inbox placement also depends on factors such as sender reputation, complaint rates, DNS, TLS, message quality and sending behavior.

Written by

Abdul Shakoor

Founder of Digital Bhatti, an independent technical publication focused on web hosting and infrastructure, WordPress, technical SEO, web performance and automation.

• About Digital Bhatti • Contact