How should DMARC, SPF, and DKIM records be configured for domains that do not send email?

Key findings

• Necessity: If a domain is never intended to send email, technically, SPF, DKIM, and DMARC records are not required for its own outbound email authentication.
• Protection: Implementing these records, especially SPF with v=spf1 -all and DMARC with p=reject, serves as a strong signal to receiving servers that any email claiming to be from that domain is illegitimate, thus preventing abuse.
• DMARC reliance: DMARC relies on SPF and DKIM authentication to function. Without legitimate email sending, the primary purpose of DMARC (to instruct mail servers on handling unauthenticated mail) is largely moot unless used purely for anti-spoofing.
• DKIM for non-senders: Setting up DKIM records for domains that don't send mail can be problematic. Without active keys, validation will fail, and some argue it adds unnecessary complexity (and may not add security value).
• SPF for non-senders: A simple v=spf1 -all record explicitly states that no server is authorized to send email from the domain. This is a clear and effective anti-spoofing measure.

Key considerations

• Future use: Always consider if the domain might send email in the future. If so, a more flexible DMARC policy, such as p=none, might be preferable initially.
• Compromise risk: If a server hosting a non-sending domain is compromised and used to send spam, properly configured DMARC and SPF can help prevent that spam from being delivered as legitimate, especially if the SPF record does not include the compromised server's IP.
• DNS records: For best practice, ensure SPF records are correctly placed in your DNS to maximize their effectiveness. Our guide on where to place email authentication records can provide more insight.
• Universal adoption: Not all email providers fully implement DMARC, so having SPF and DKIM in place (even if simple) can still offer some protection or clarity to legacy systems. An M3AAWG paper on parked domain best practices recommends explicit configuration.

Key opinions

• Minimalist approach: If a domain will truly never send email, some marketers believe no SPF, DKIM, or DMARC records are strictly necessary.
• Value in explicit declaration: Many see significant value in explicitly telling the world that emails from a given domain are not legitimate if they appear, acting as a strong anti-spoofing measure.
• SPF as primary defense: A common practice is to publish a v=spf1 -all record for non-sending domains, indicating no authorized senders exist.
• DMARC with reject policy: Coupling the SPF record with a DMARC p=reject policy is considered the strongest stance against domain misuse for non-sending domains.
• DKIM complexity: DKIM is often viewed as less essential or even unnecessary for non-sending domains due to the absence of keys for validation, potentially adding complexity without tangible benefit.

Key considerations

• Spoofing prevention: Even if a domain doesn't send email, it can still be targeted by spoofing. Proactive DMARC and SPF setup reduces this risk, minimizing your chances of landing on a blocklist or damaging your brand's reputation.
• Compromised infrastructure: If the hosting server for a non-sending domain is compromised, an attacker could try to send emails from that domain. Proper SPF and DMARC prevent these unauthorized emails from passing authentication checks, regardless of attacker attempts to install mail servers.
• Simplicity vs. security: While simply doing nothing is an option, adding a minimal SPF and DMARC record (e.g., v=spf1 -all; v=DMARC1; p=reject;) is a straightforward way to add a layer of security without significant effort.
• Monitoring DMARC: Even for non-sending domains, DMARC reports (if enabled with a rua tag) can provide valuable insights into attempted spoofing. Learn more about how DMARC works to understand its reporting capabilities.

Key opinions

• Holistic approach: Experts recommend considering SPF and DKIM records even if DMARC isn't universally adopted by all Mailbox Providers (MBPs).
• Strongest stance: Publishing a v=spf1 -all record combined with a DMARC p=reject policy is considered the most secure configuration for non-sending domains.
• DKIM's role: The utility of DKIM for non-sending domains is questionable, as validation hinges on the existence of configured keys, which would be absent.
• Revocation of keys: For active domains, explicitly revoking a DKIM key (e.g., p=) is a rare but useful scenario, but for non-sending domains, simply not publishing them or deleting existing ones is sufficient.
• DNS operational best practices: Configuration should always align with good DNS operational experience rather than overly complex or theoretically driven approaches.

Key considerations

• Prevention of domain misuse: Proactively setting up DMARC, SPF, and potentially DKIM, is a robust defense against domain spoofing and phishing, ensuring that your domain cannot be easily exploited for malicious purposes.
• Standardization: Adhering to standards, such as those discussed in our guide on A simple guide to DMARC, SPF, and DKIM, even for non-sending domains, contributes to a safer email ecosystem.
• Simplicity in DKIM: For domains that don't send email, it is generally recommended to simply not publish DKIM keys rather than attempting complex wildcard configurations.
• Long-term security: While initially seemingly unnecessary, these records provide a foundational layer of security for the domain's identity in the long run. Resources like Word to the Wise offer historical context and ongoing advice for managing domain reputation.

Key findings

• DMARC policy for non-senders: DMARC's primary purpose is to allow a domain owner to indicate that their emails are protected by SPF and/or DKIM, and to tell a receiving mail server what to do if the authentication fails. For non-sending domains, a p=reject policy clearly signals that no email from this domain should ever be accepted.
• SPF for non-senders: SPF allows domain owners to specify which mail servers are authorized to send email from their domain. For a non-sending domain, the -all mechanism in a v=spf1 -all record explicitly states that no hosts are authorized to send mail from the domain, instructing recipients to reject any mail from it.
• DKIM key revocation: RFC 6376, which defines DKIM, suggests that to indicate a revoked key, one can leave the "p" (public key) field with no value in the DKIM TXT record (e.g., v=DKIM1; p=). This serves as an explicit signal of non-authorization.
• Wildcard DKIM records: Some documentation (like the M3AAWG paper) has proposed using wildcard DKIM records (e.g., *._domainkey.example.com TXT "v=DKIM1; p=") to ensure any selector for the domain is explicitly unauthorized, though the practical utility and wisdom of this are debated.

Key considerations

• Clarity of intent: For domains that explicitly do not send email, clear SPF and DMARC configurations (e.g., SPF -all and DMARC p=reject) communicate to receiving servers that any email originating from this domain is unauthorized.
• Minimizing attack surface: These explicit policies reduce the domain's vulnerability to email spoofing and phishing, mitigating potential brand damage or blocklisting.
• Complexity vs. benefit: While some technical documents suggest intricate DKIM configurations for non-sending domains, simpler approaches, such as not publishing keys at all, are often more practical and sufficient given the lack of outbound mail.
• DMARC reporting: Even with a p=reject policy, setting up DMARC aggregate (RUA) reports can provide valuable data on attempted domain misuse, as outlined in DMARC RFC 7489.