How Receiving Mail Servers Handle Messages With No SPF, DKIM, or DMARC Records

A message whose sending domain publishes no SPF, DKIM, or DMARC records is never rejected by rule. Each of the three checks simply reports a result of none, and the receiving server then applies its own local policy — which may mean normal delivery, a spam score penalty, or refusal for bulk senders, depending entirely on how that particular receiver is configured.

Three checks, three "none" results

The three mechanisms are evaluated independently, and a missing record affects each differently:

• SPF (RFC 7208) is checked against the envelope sender — the MAIL FROM address, or the HELO name when the envelope sender is empty — not the From: header. If the domain publishes no TXT record beginning with v=spf1, the evaluation result is none. The receiver may log this in a Received-SPF or Authentication-Results header, but nothing in the standard tells it to refuse the message.
• DKIM (RFC 6376) only runs when the message actually carries a signature. No DKIM-Signature header means there is nothing to verify, so the receiver records dkim=none or no DKIM result at all. Unsigned mail is not a protocol failure.
• DMARC (RFC 7489) asks the receiver to look up a policy at _dmarc.<domain> for the domain in the From: header. With no record published, there is no sender-declared policy to enforce, so DMARC evaluation does not apply and the receiver relies on its own judgment.

Why the standards leave the decision open

The RFCs define how records are evaluated and which result strings are produced, but they deliberately stop there. Whether to accept, tag, quarantine, or refuse a message is left to local policy, because receivers range from personal servers to providers handling billions of messages, with very different risk tolerances. The distinction worth internalising: none is not fail. A fail means records exist and the message contradicts them; none means there is no evidence either way. No specification treats absence of evidence as grounds for rejection.

How common receivers treat "none"

In practice, outcomes vary widely:

• A stock Postfix server with no policy or milter add-ons accepts the message outright — it never evaluates SPF, DKIM, or DMARC in the first place. Rejection only happens if you attach something like an SPF policy daemon, OpenDKIM/OpenDMARC milters, or Rspamd, and configure it to act on none.
• Spam filters such as Rspamd and SpamAssassin treat none as a small negative signal rather than a verdict. Rspamd exposes symbols like R_SPF_NA and DMARC_NA; SpamAssassin has comparable rules. The message is spam-foldered only if the total score — combining authentication with reputation, content, reverse DNS, and more — crosses the threshold.
• Large providers (Gmail, Yahoo, Microsoft) now require bulk senders to publish SPF or DKIM plus a DMARC record, and unauthenticated bulk mail may be refused or routed to spam. Low-volume, person-to-person mail without records is typically still accepted, just weighted more heavily by spam filtering.

Diagnosing what happened to a message

The receiving server's decision trail is written into the message itself. Look at the Authentication-Results header on a delivered message:

Authentication-Results: mx.example.com;
    spf=none smtp.mailfrom=example.org;
    dkim=none;
    dmarc=none

To confirm what a domain actually publishes, query DNS directly — the SPF record lives on the domain itself, while DMARC lives on the _dmarc subdomain:

dig +short TXT example.org
dig +short TXT _dmarc.example.org

What senders should do about it

Relying on receivers' leniency is fragile, because each provider can tighten its policy at any time. Publishing records costs little and turns silence into a signal. A minimal starting point:

example.org.        TXT  "v=spf1 include:_spf.example.net ~all"
_dmarc.example.org. TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

A p=none DMARC policy enforces nothing but activates aggregate reports, letting you see which legitimate sources send mail for your domain before tightening to quarantine or reject. Signing with DKIM at your submission server or provider covers the cases SPF cannot, such as forwarded mail.

Frequently Asked Questions

Does missing SPF, DKIM, and DMARC cause a hard bounce?

No. No specification requires rejection on absent records. Any rejection is a local policy decision by the receiving administrator or provider.

Is a "none" result the same as a "fail"?

No. fail means records exist but the message does not match them. none means no records were found, so there is nothing to compare against. Filters treat the two very differently.

Which domain is checked by SPF versus DMARC?

SPF evaluates the envelope sender (MAIL FROM, falling back to HELO when the envelope sender is empty). DMARC aligns with the domain in the visible From: header. The two can legitimately differ.

Can I make my own server reject mail with no authentication records?

Yes, via policy services or milters — for example an SPF policy daemon, a DMARC milter, or Rspamd rules — but be careful: much legitimate mail from mailing lists, forwards, and small servers carries no records, so strict rejection on none produces false positives.

Do Gmail and Yahoo reject mail without these records?

For bulk senders, effectively yes — under their sender requirements, unauthenticated bulk mail can be refused or spam-foldered. Small-volume personal mail is usually accepted but scores worse in spam filtering.

Where can I see what a receiver decided?

In the Authentication-Results header of the delivered message, which lists the spf, dkim, and dmarc results, plus any Received-SPF header the server added.