Delegation of SPF Domains

When looking at internal sources in the Enforce Authentication dashboard, it is not uncommon to see an internal source sending with multiple EnvelopeFrom/ReturnPaths which show as Aligned SPF Domains in the report. In some cases there may be a large number of these Aligned SPF Domains.

While it is possible to delegate all of these subdomains to Enforce, it may not be necessary. If the internal source supports DKIM signing, it will be easier to DKIM sign these emails and allow these emails to only authenticate via DKIM.

Dealing with large numbers of internal sources

If the customer has large numbers of internal sources, it may be possible for the customer to configure these servers to send all emails through an email relay. This relay could be the customer's existing public email gateway or it could be an internal system that is configured as a relay.

Hostnames as SPF domains

It is common to see some internal sources sending emails with an SPF domain that is a hostname of a server. This will normally be the internal system appearing to send from its own hostname.

This is a factor of the DMARC reports and these hostname SPF domains are normally not legitimate.

This traffic is normally due to email bounces. When a server can not deliver an email and sends a bounce message back to the sending server, it will not include an EnvelopeFrom to prevent possible mail bounce loops. The reason we see these in the dashboard is that when the receiver of the bounce email generates its DMARC report for the day, it will often populate the SPF domain field with the hostname of the sending server rather than leaving it blank. 

In these cases, we will not add the hostname as a subdomain in the Enforce configuration screen. To ensure that these bounces continue to be delivered after enforcement, the sending server should enable DKIM signing. This will allow the bounce emails to pass DMARC.