A common misconception about SPF

SPF looks at the bounce address of an email when doing its check.  (The bounce address is also referred to as the Return-Path, the MAIL FROM address, the envelope address, and in some circles, the RFC5321.MailFrom address.)  When SPF does its check, it will look for an SPF record using the domain found in the bounce address. DMARC attempts to correlate the results of checking SPF and DKIM with the domain found in a message's From: header.  It's the domain of…
30 November 2015

How can SPF/DKIM pass, and yet DMARC fail?

DMARC introduces the concept of "Identifier Alignment" to the world of email.  The concept is needed as SPF and DKIM are stand-alone technologies capable of associating a domain with a piece of email. When a receiver uses SPF, the receiver looks at the domain found in the RFC5321.MailFrom to figure out where to look for an SPF record.  The RFC5321.MailFrom address is the entity that is passed along as part of the "MAIL FROM" command during the SMTP conversation.  To…
12 October 2015

Broken SPF.. what does it mean?

People sometimes write in and ask "what is the impact of a broken SPF record"? The net effect of a broken SPF record is that receivers can't reliably use SPF to determine the legitimacy of the domain's email.  *Some* receivers might ignore the broken parts of an SPF record and keep checking, but out of the box all SPF implementations will barf, and you'll be left with a record that is introducing uncertainty into email performance. We've discovered an odd…
10 October 2015

PTR mechanisms in SPF records

If PTR mechanisms are detected, the current diagnostic output is: Warning: PTR mechanisms SHOULD NOT be used and cannot be resolved using this diagnostic tool.  More info at <this page!>. What does the PTR mechanism mean?  When an email receiver gets a piece of email and the PTR mechanism is in the sender's SPF record, the receiver will look at the incoming IP address and do a "PTR" lookup.  For example, if the sender is sending email from IP address…
9 October 2015

Brief history of email authentication

Email is huge (largest deployed application on the Internet?) and it takes a long time to change the fundamentals. 2003: First SPF draft 2004: First DomainKeys draft (predecessor to DKIM) 2006: First DKIM draft PayPal begins work with Yahoo on authentication-based model 2007: BITS Email Security Working Group publishes paper recommending TLS + SPF + DKIM for email DKIM RFC published PayPal + Yahoo blocking based on DomainKeys+SPF goes live 2008: PayPal publishes "A Practical Approach To Managing Phishing" 2009:…
5 October 2015