Posts and Articles

It was back in 2023 when Google and Yahoo simultaneously announced that they would start penalizing senders who did not follow their guidelines. The announcement caused some panic because many domains didn’t have DMARC records, some ESPs only DKIM signed messages with a shared domain, and many ESPs did not support RFC 8058 which describes the required one-click unsubscribe mechanism. Now in 2026 the dust has settled and other providers have since announced enforcement of their own bulk sender requirements to little fanfare; mainly because all of the heavy lifting was done achieving compliance with Google and Yahoo. ...

Beginning September 2026 Google will allow qualifying US political senders to enroll their domains in the Gmail Verified Sender Program. The program requires that the sender follow existing bulk sender guidelines, use Google Postmaster Tools, and not send spam. In return Gmail’s filters will treat the sender differently. Background In 2022 an academic paper1 was published which concluded that message filters exhibited political bias during the 2020 (US) election. It didn’t matter that the paper conflated the supposed bias with normal filter operations or that it found that bias was not uniformly in favor of one party. The genie was out of the bottle. Legislation was proposed2 which would compel filter operators to exclude political messages from decision making algorithms; messages could still be manually blocked or marked as spam by the recipient. ...

I have previously explained the important part permission can play in successful mail programs. But what if you intend to send messages to people who never gave you any level of permission to do so? You may feel entitled to send these messages because they have a veneer of legitimacy such as implied consent or legal permissibility. But is is really a good idea? Implied consent Implied consent is when you collect an email address but fail to also collect explicit permission use it for marketing purposes. Sometimes that’s fine because the address was surrendered with an assumption that that it would be used for marketing. Sometimes it’s not fine because no such assumption was made. How do you know the difference without waiting for complaints? Get any contacts with implied consent properly permissioned before you start sending marketing messages to them. Reluctance to take this step is proof of how weak you know the implied part really is. ...

Spammer math is basically any variation of the following line of reasoning: if I get one sale from a send to one thousand messages that means that I will get one hundred sales sending to one hundred thousand messages and so on until infinity. It can be expressed as (s=cm) where s is sales, c is the conversation rate, and m is the number of messages sent. This model is based on the idea that sales will scale at a constant multiplier relative to messages sent. The foil here is probability. The assumption is that each message sent has the exact same independent probability of converting. This is false because as the number of messages increases so too does the probability of bounces and complaints, which increases the probability of sender reputation problems which in turn causes the probability of conversions to increasingly diminish. In economics this is often referred to as the law of diminishing returns. ...

Sending mail to people who didn’t ask for it is often just asking for trouble. Having people give you permission to send to them is much better. In an ideal world you want first-party consent meaning that people directly subscribed to your list. You have measures in place to confirm that they really did sign up and someone didn’t just stuff their address into a subscription form. These people want your emails. ...

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 hostname: 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. ...