Summary
For domains that do not send email, the strong consensus is to implement SPF and DMARC to prevent domain spoofing, phishing, and unauthorized use. The recommended SPF record is `v=spf1 -all`, which explicitly states that no email should originate from the domain. The recommended DMARC policy is `p=reject`, which instructs receiving mail servers to reject any messages claiming to be from the domain that fail DMARC checks. While DKIM is not strictly required, experts recommend deleting existing DKIM keys and avoiding publishing new ones. Accurate syntax for SPF and DMARC records is critical for preventing deliverability issues.
Key findings
- SPF Record: Set the SPF record to `v=spf1 -all` to definitively indicate that the domain does not send email.
- DMARC Policy: Configure the DMARC policy to `p=reject` to instruct receiving servers to reject unauthorized emails.
- DKIM Configuration: DKIM is optional; remove any existing DKIM keys and avoid publishing new ones for non-sending domains.
- Spoofing Prevention: Implementing SPF and DMARC prevents domain spoofing, phishing attacks, and unauthorized email activity.
- Record Syntax: Accurate syntax in SPF and DMARC records is essential to prevent deliverability issues.
Key considerations
- Future Use: Consider whether the domain might send email in the future and plan for proper authentication if needed.
- DKIM Revocation: Explicit DKIM key revocation is rarely necessary but should be considered if a key was compromised and misused.
- Policy Enforcement: Ensure that the DMARC policy is correctly implemented to effectively reject spoofed emails.
- Monitoring: Consider starting with a less restrictive DMARC policy (e.g., `p=quarantine` or `p=none`) to monitor and assess the impact before fully enforcing `p=reject`.
What email marketers say
10 marketer opinions
For domains that do not send email, the consensus is to implement SPF and DMARC to prevent domain spoofing and unauthorized use. The recommended SPF record is `v=spf1 -all`, indicating that no email should originate from the domain. The recommended DMARC policy is `p=reject`, instructing receiving mail servers to reject any messages claiming to be from the domain that fail DMARC checks. While DKIM isn't strictly necessary, it can be implemented.
Key opinions
- SPF Record: Set SPF record to `v=spf1 -all` to indicate no email should ever originate from the domain.
- DMARC Policy: Set DMARC policy to `p=reject` to instruct receiving servers to reject unauthorized emails.
- DKIM: DKIM is optional but can be implemented; otherwise, ensure no DKIM keys are published.
- Spoofing Prevention: Implementing these measures prevents domain spoofing, phishing attacks, and unauthorized email activity.
Key considerations
- Future Use: Consider if the domain will ever send email in the future. If so, proper authentication should be configured then.
- DMARC Reporting: While `p=reject` is the goal, consider starting with `p=quarantine` or `p=none` to monitor results before fully enforcing the reject policy.
- Syntax Accuracy: Ensure accurate syntax for SPF and DMARC records to avoid deliverability issues.
Marketer view
Email marketer from EasyDMARC advises deploying SPF `v=spf1 -all` and DMARC `p=reject` for non-sending domains, which minimizes the risk of domain spoofing and phishing attacks.
29 Mar 2022 - EasyDMARC
Marketer view
Email marketer from StackOverflow suggests setting DMARC policy to `p=reject` with appropriate SPF (`-all`) even for parked domains. This prevents unauthorized use of the domain for spam or phishing.
20 Aug 2024 - StackOverflow
What the experts say
3 expert opinions
For domains that do not send email, experts recommend implementing SPF and DMARC to prevent phishing attacks and unauthorized use. The recommended SPF record is `v=spf1 -all`. The DMARC policy should be set to `p=reject`. DKIM keys should be deleted; explicit revocation is rarely necessary, only in cases of misuse or compromise.
Key opinions
- SPF Record: Use `v=spf1 -all` to indicate the domain never sends email.
- DMARC Policy: Set DMARC policy to `p=reject` to prevent unauthorized use for phishing.
- DKIM Key Management: Delete existing DKIM keys and do not publish new ones. Explicit key revocation is rarely needed.
Key considerations
- Potential Misuse: Consider explicit DKIM key revocation only if the key was compromised and misused.
- Policy Enforcement: Ensure DMARC policy is correctly implemented to effectively reject unauthorized emails.
Expert view
Expert from Email Geeks shares that he publishes a `v=spf1 -all` record for domains that don't send email, along with a DMARC p=reject policy.
30 Aug 2024 - Email Geeks
Expert view
Expert from Word to the Wise recommends setting up a DMARC record even for domains that don't send mail, to prevent them from being used in phishing attacks. He suggests a reject policy (`p=reject`).
24 Aug 2023 - Word to the Wise
What the documentation says
5 technical articles
For domains that do not send email, documentation recommends setting an SPF record to `v=spf1 -all` to explicitly state that no email should originate from the domain. DMARC should be configured with a policy of `p=reject` to instruct receiving servers to reject unauthorized emails. DKIM is not strictly required, but if implemented, a wildcard record can invalidate all keys. Accurate syntax is critical for SPF record effectiveness.
Key findings
- SPF Configuration: The SPF record should be set to `v=spf1 -all` to prevent email origination from the domain.
- DMARC Policy: The DMARC policy should be `p=reject` to reject unauthorized emails claiming to be from the domain.
- DKIM Requirement: DKIM is optional; if implemented, invalidate all keys using a wildcard.
- Record Syntax: Correct syntax is vital for proper functionality and preventing deliverability issues.
Key considerations
- DKIM Implementation: Carefully consider whether to implement DKIM at all for non-sending domains.
- Policy Enforcement: Ensure proper DMARC policy enforcement to effectively reject spoofed emails.
Technical article
Documentation from DMARC.org advises setting a DMARC policy of `p=reject` for domains that do not send email. This instructs receiving mail servers to reject any messages claiming to be from the domain that fail DMARC checks.
28 Aug 2023 - DMARC.org
Technical article
Documentation from Microsoft mentions that DKIM is not strictly required for domains that do not send email, but it can be implemented with a wildcard record to explicitly invalidate all keys if desired.
25 Jan 2024 - Microsoft
Are DMARC RUA and RUF tags mandatory for compliance and what are their benefits?
Are SPF, DKIM, and DMARC records necessary for transactional email servers not used for marketing?
Can I set DMARC to reject if my domain doesn't send email?
Do all email service providers support DMARC, and what does 'support' mean in this context?
Do I need DMARC for transactional emails from a small website, and what are the best low-cost alternatives for sending emails if my IP is blocked?
Do Yahoo and Gmail require DMARC authentication for senders?
