SPF and DMARC email security
SPF and DMARC help receiving systems evaluate whether mail is authorized to use a domain and how authentication failures should be handled. Strong policies reduce some forms of spoofing, but they authenticate domain use and alignment rather than the real-world identity or intentions of the person sending a message.
- SPF presence is less informative than the actual policy that was published.
- DMARC p=none is a monitoring policy; quarantine and reject request different handling for authentication failures.
- SPF and DMARC can be configured correctly on a maliciously registered domain.
- MTA-STS and TLS-RPT address transport security and reporting, not sender trustworthiness.
SPF: authorization for SMTP identities
SPF is defined in RFC 7208. A domain publishes a TXT policy describing which hosts are authorized to use that domain in the SMTP MAIL FROM or HELO identities. Receiving systems evaluate the policy during message handling.
More detail
A checker should therefore inspect more than whether “v=spf1” exists. Multiple SPF records can invalidate evaluation, an unqualified or +all mechanism can be overly permissive, and policies with too many DNS-dependent mechanisms can exceed the SPF processing limit.
DMARC: alignment and handling policy
DMARC is standardized in RFC 9989. It evaluates whether authenticated identifiers align with the domain visible to the user and lets a domain owner publish a requested handling policy for failures.
More detail
The policy value matters. p=none is intended for monitoring and reporting rather than requesting quarantine or rejection. p=quarantine and p=reject request different handling for authentication failures. RFC 9989 removed the historic pct tag and defines the t tag for testing behavior, so this checker treats t=y as a testing signal rather than scoring legacy pct values.
Why strong authentication does not equal a safe sender
A threat actor who legitimately controls a domain can configure SPF and DMARC for that domain. Authentication can then succeed even though the message itself is deceptive. The protocols answer questions about authorized use of a domain; they do not certify the business, person or offer described in the message.
More detail
That is why Can I Share This? combines authentication posture with domain identity, registration age, disposable-provider checks and lookalike analysis rather than turning SPF or DMARC into a binary scam verdict.
MTA-STS and TLS reporting
MTA-STS, defined in RFC 8461, lets receiving domains publish a policy for TLS-secured SMTP delivery. TLS-RPT, defined in RFC 8460, provides reporting about TLS delivery failures. These are useful signs of mail-security maturity.
More detail
Their absence is common and is not treated as evidence of a scam. In the checker they are presented as technical posture information rather than major risk-score penalties.
DNSSEC and registration data
DNSSEC can provide cryptographic protection for DNS data when the delegation and validating resolver path support it. As with MTA-STS, the presence or absence of DNSSEC is not a sender-identity verdict.
More detail
Registration age comes from public RDAP data on a best-effort basis. It is a separate contextual signal: a very young domain can increase uncertainty, while a long registration history does not guarantee that a mailbox or account has not been compromised.
Primary references
These references define or document the email and domain-security concepts discussed above.
Related email and link safety pages
Check a suspicious email address
Paste the address into the same Can I Share This? scanner used for suspicious links. The checker automatically detects that the input is an email address.