Addressing problems sending email to Google, Microsoft 365 or BT Internet Mail Servers

Overview:

These ISP’s may have previously been accepting emails from your domain or mail server IP address without issue, then with no obvious changes at your end, begin refusing some or all email from you with responses like this:

550-5.7.26 This message does not have authentication information or fails to
550-5.7.26 pass authentication checks (SPF or DKIM). To best protect our users
550-5.7.26 from spam, the message has been blocked. Please visit
550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more
550 5.7.26 information.

550-5.7.1 Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked. Please visit
550-5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError
550 5.7.1 for more information

554 Message rejected on <DATE> BST, policy (3.2.1.1) ID (628C2B830293CAD8) – Your message looks like SPAM or has been reported as SPAM

What checks / changes do I need to make to resolve this?

The initial step is to check that nothing has changed which might explain this. We would recommend that you use sites like the below to confirm that your public IP address is not being treated poorly as its listed on blacklists:

MX Toolbox Blacklist Check

Trend Micro IP Reputation Check

Barracuda Domain / IP Reputation Check

If you are listed on a blacklist or have a poor reputation, these sites will typically give specifics as to the cause of the listing so you can investigate your mail server or network further before requesting a delisting.

If you are not listed, then a likely cause is that the receiving mail server is now performing additional steps to validate your domain and sending IP address and you are failing these checks. These ISP’s will often validate your sending domain and the mail server location it arrived from using mechanisms such as PTR, SPF, DKIM and DMARC so it’s very important you have these correctly configured.

PTR Configuration:

A PTR record, is often also referred to as a Reverse DNS record and is a check a receiving mail server makes when you initially establish an SMTP connection to them. It is a hostname that your public Internet IP address resolves to. That hostname should then be an A record that resolves back to the same IP address.

For example, the public IP address assigned to our Zen Software mail server is 54.171.249.78 and we have a PTR record configured on that IP address in DNS which resolves to mail.zensoftware.co.uk.

We also have an A record in DNS called mail.zensoftware.co.uk which resolves back to 54.171.249.78.

Finally, we’ve configured our HELO/EHLO domain on our mail server to be mail.zensoftware.co.uk so that any lookups against this hostname also resolve back to the IP address the receiving mail server sees is connecting. The HELO/EHLO domain is configured in the following locations:

MDaemon: Setup -> Domain Manager -> domain.com -> Host name & IP -> SMTP Host name

SecurityGateway: Setup / Users -> Mail Configuration -> Email Protocol -> HELO Domain Name

SPF Configuration:

SPF is designed to specify the server locations that are allowed to send email for your domain. When receiving mail servers get a message from your domain, they compare the sending server to your list of allowed servers. This lets receiving servers verify the message actually came from you. An SPF record is an entry in the DNS record for your domain name and defines all the hostnames and IP addresses that valid email from your domain name will arrive from.

This article details how to configure the SPF DNS record required.

DKIM Configuration:

DKIM (Domain Keys Identified Mail) is an email authentication method that allows a recipient mail server to check that an email was definitely sent and authorised by your domain name. This is achieved by giving the email a digital signature. The signature is a unique encrypted header that is added to the email by your mail server.

The DKIM signing configuration process is explained in these guides:

MDaemon

SecurityGateway

DMARC Configuration:

DMARC checks for alignment and defines the action the receiving mail server should take if an email you send to them fails DKIM or SPF verification. It is a DNS record you publish in the public DNS for your domain. The DMARC DNS record setup is explained here but it would typically look similar to this:

_dmarc.domain.com text =”v=DMARC1; p=quarantine”

In this example, a recipient mail server that receives email claiming to be from user@domain.com, but that fails SPF or DKIM verification would accept and then quarantine that email for further review.

If you would prefer the recipient mail server just rejects email that claims to be from your domain, but is in fact not, then the p= value would be reject instead.

Further steps:

Typically, the use of these authentication methods is enough to prevent issues sending to these ISP’s. If problems persist, though you may find the following links useful:

Google provide Postmaster Tools provides data regarding your sending domain email

Microsoft’s Smart Network Data Service provides data regarding your sending IP address

Emailing postmaster@btinternet.com can help you advise BT that you have setup valid PTR, SPF, DKIM and DMARC records and request mitigation / further details regarding the listing they have in place for your sending domain name or IP address.