Improving DMARC Compliance: Authenticated SMTP Relay

I've done a lot of server migrations for very unrelated reasons over the last six months or so. Many of these host applications that send emails, and I've implemented the basics to get them sending DMARC-compliant messages. This has generally been limited to DNS SPF records for each host configuration. Generally speaking, having SPF or DKIM compliance is 'enough' to get your messages not flagged as spam, though it can depend on the DMARC policy configuration.

A Trigger for a Change

Exacerbated by the forthcoming retirement of the "old" Google Apps for Business/free tier, I was looking for viable and low-cost ways to preserve "sending as" a custom domain but leveraging a free Gmail account for a client with super low-volume email needs. This client does not want to pay for a Workspace subscription to keep the custom email. We've been addressing email receipt via forwarding for many years, but we now needed a way to send in a complaint way—preferably without spinning up a full-on MTA and dealing with all of that crazy business.

Enter Authenticated SMTP Relay

After considering many options, I settled on giving Sendgrid a try for this case (there are several similar products and services available). The client in question easily falls into the lower-end of the "free" tier and using the service would keep their email "behaving" as it was, and would not change in appearance to those with whom they communicate. Signing up for the service was trivial, and with DNS access we were up and running (and sending an authenticated test message) in just a few minutes.

We set up an authenticated relay with their API after verifying control over the domain (via DNS), and in so doing not only do we get DMARC-compliant SPF sending, we also get DKIM-signed messages through the relay as well. Opening test messages on the receiving side, it's easy to see all three bits are PASSing!

With the normal email problem solved, and given how simple it was to create API keys for distinct services, I thought this could be an easy change for some of these freshly-changed servers with low-volume email needs. And bolster email deliverability and trust.

The Server Application Change

In most of my use cases, changing default MTA settings on the server itself was not necessary because I don't want the server itself to send public messages, though there were a couple of exceptions. The applications within, however, are where I needed to make the change. Apps like Drupal, WordPress, and other products usually make setting a specific SMTP relay pretty straightforward through the application configuration interface. Services such as Sendgrid give you a user/pass with their API keys that can be plugged into most services. Used judiciously and per the provider's terms, using the free tier thus far has been great!

In everything I've set up thus far with such an authenticated relay, the need to track has not been necessary or desired. Finding the default tracking settings can be a little weird, but after making such changes I'm only seeing basic deliverability stats and not details about click tracking or opens. Exactly the desired outcome, and definitely improved deliverability and trust.

Reports Can Confirm

I've written about my DMARC report analysis before, and following this change the services where I've moved to an authenticated SMTP relay are really night-and-day from their previous configurations. Specifically, those changes lead to more records like this:

    <row>
      <source_ip>123.234.56.78</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>

Final Thoughts

I'm really glad to have free-tier providers (and several from which to choose) for authenticated SMTP relay, because in these low-volume circumstances it's a great way to make things better without a lot of overhead or the burden of trying to manage one's own MTA with all of today's considerations (it's not the 1990's anymore). Incremental changes in making email better is good for everyone!