Summary
Configuring DMARC, SPF, and DKIM for domains that do not send email is a nuanced topic. While some argue that these records are unnecessary if a domain will never transmit email, others advocate for their implementation as a protective measure against spoofing and phishing attempts. The consensus leans towards implementing at least SPF with a v=spf1 -all record and a DMARC policy set to p=reject for domains that explicitly should not send mail. DKIM's utility for such domains is debated, as it relies on keys that would not be used, potentially leading to unnecessary complexity without additional security benefits.
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.
What email marketers say
Email marketers often approach DMARC, SPF, and DKIM for non-sending domains from a practical, risk-averse perspective. While acknowledging the technical redundancy if no emails are sent, many still see value in setting up basic authentication records to prevent domain spoofing and enhance overall brand security. The discussion frequently revolves around balancing simplicity with effective protection against malicious actors attempting to impersonate the domain.
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.
Email marketer from Email Geeks queries the necessity of DMARC, SPF, and DKIM for domains that never send email, along with a proposed DMARC record example.
Email marketer from Email Geeks states that if domains are strictly non-sending, these authentication records are not required.
What the experts say
Experts generally agree on the importance of robust DNS configurations for domains, whether they send email or not. For domains not intended to send email, the consensus favors a clear and unambiguous declaration of this fact via SPF and DMARC records. While the necessity of DKIM for non-sending domains is debated, the overarching principle is to minimize the potential for domain abuse through explicit authentication policies, thereby protecting the domain's reputation and preventing it from being weaponized in phishing campaigns.
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.
Email expert from Email Geeks recommends setting up SPF and DKIM records even if not all Mailbox Providers (MBPs) use DMARC, citing an M3AAWG paper for best practices.
Email expert from Email Geeks confirms using a v=spf1 -all SPF record and a DMARC p=reject policy for their domains that do not send email.
What the documentation says
Official documentation and RFCs provide the foundational guidelines for email authentication protocols. For domains that do not send email, these documents emphasize clarity and security. While not always explicitly detailing configurations for non-sending domains, the principles of DMARC, SPF, and DKIM suggest that a strong defensive posture is achievable through specific DNS record entries. This often involves defining what *shouldn't* happen with a domain's email, rather than what should.
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.
Documentation from RFC 7208 on SPF recommends using a "-all" mechanism (e.g., "v=spf1 -all") to indicate that no IP addresses are authorized to send mail from a specific domain, serving as a clear directive for non-sending domains.
Documentation from RFC 7489 (DMARC) states that a domain owner can use a "p=reject" policy to instruct receiving mail servers to reject all messages that fail DMARC authentication, effectively blocking unauthorized mail from domains not intended to send email.
