Posts and Articles

Google recently proposed a new method for verifying that an email address exists without sending a verification message to the address. They are calling it the Email Verification Protocol and there is an associated Internet Draft. The idea is that the verification process all happens within the web browser at the point of address submission instead of being split between the website and wherever email lives. Not using email to verify the validity of an address removes friction such as sending delays and message filtering false-positives. ...

Many senders have concerns about sending bulk email with PDF attachments. ESPs often advise customers against doing so and suggest alternate solutions like linking to a web portal that has the PDF file. This is all very sensible. But what happens if you must send an PDF attachment due to a regulatory or some other mandatory requirement - is the campaign guaranteed to fail? The answer is no. It is possible to send a PDF attachment as part of a bulk campaign and give it a very good chance of reaching inboxes. ...

I mentioned in a previous post that DKIM and SPF have known vulnerabilities. SPF has two that are currently being exploited. The first one exploits over-broad include mechanisms and what constitutes SPF being considered to pass. For example if the SPF record for domain.victim looked like this: v=spf1 +include:_spf.google.com +include:hosting.provider ~all If you can control an IP within the range covered by hosting.provider then you can do something like this: SMTP HELO/EHLO address: kflynn@domain.hacker ...

I mentioned in a previous post that DKIM and SPF have known vulnerabilities. The main weakness with DKIM is that you can replay the messages. By design DKIM signed messages are replay-able meaning that under certain conditions you can send a DKIM signed message from A to B then B can replay the unmodified messages to C (or any number of recipients) and the signature will still validate. This works because DKIM does not sign the return-path message header or concern itself with message delivery at all. After all DKIM was always about content signing. ...

RFC 8619 was published in July 2019 with the status of Experimental and describes the Authenticated Received Chain (ARC) protocol. On 16 April 2026 the DMARC Working Group (who originated ARC) voted to re-charter the group for the sole purpose of changing the status of the RFC to Historic and declaring the ARC experiment concluded. I was one of those who voted in favor. The WG has six months to agree on actually doing this. If successful then there will be no further updates to the specification and deployment will not be recommended. ...

The DKIM Working Group are developing a spiritual successor to DKIM. They have named it DKIM2 but it is more of its own thing than an iterative new version of the original DKIM protocol. As of now (June 2026) it is still going through the drafting process so there is no RFC or stable specification to develop against. Ideas are still being stress tested and edge cases considered. The latest Internet-Draft can be viewed here and there is also an explanatory website operated by the WG here. ...

The original DMARC specification was published back in March 2015 as RFC 7489 and had a status of “Informational”. A new revision published in May 2026 breaks the specification into multiple RFCs and has a status of “Proposed standard”. This is the first step to becoming an Internet Standard. The new DMARC RFCs: RFC 9989 - core protocol specification RFC 9990 - aggregate reporting specification RFC 9991 - failure reporting specification In the approximately ten years between these two revisions the specification has been refined but not radically altered. The updated specification is fully backward compatible with the previous one. ...

Just a short note to say that yes the website is still alive! Apologies for the radio silence. The site’s hosting has been migrated to something more manageable and faster. The blog will start to get more regular updates on changes affecting the email industry. There’s a backlog of unpublished posts in various degrees of completeness and also some very interesting changes happening in 2026. Stay tuned.

2024 Update: Gmail and Yahoo! Change Their Sending Requirements Last updated: 10 August 2024 Refer to Chapter 8 (Sender Reputation) and Chapter 11 (Email Authentication) of Email Deliverability Explained (2nd edition) for background information on topics discussed in this post. Back in October 2023 Google and Yahoo! simultaneously announced that they would begin enforcing new requirements for bulk senders from February 2024 onwards. By June 2024 all of the new requirements are officially being enforced. ...

Publication - Email Deliverability Explained (second edition) is now live on Amazon Delighted to announce that the second edition of Email Deliverability Explained is officially available as of today on Amazon. It took a long while to get here, but it was worth it. I have plans to release a Kindle edition at some point, but not immediately. The print edition always more popular historically. As any self-published author will tell you, it’s a team effort. I would like to thank everyone who helped make this possible. You know who you are.