Need to check DMARC settings for custom domains

Apologies for something that only affects a subset of Tidbit users … but this is something that isn’t yet as well-known as it should be …

If you send and receive email for a custom domain (using – for example --a custom domain with Google Workspace aka G Suite aka Gmail for Business) you need to be sure that your domain’s DMARC settings are correct. Especially if you maintain mailing lists for your custom domain. If you don’t, a lot of your mailings could start bounding soon.

To make a long story short, hackers are currently sending a LOT of fake sender email phishing email messages:

In reaction to the hacker’s efforts, email providers (e.g., Google, Yahoo, and Apple) all of a sudden want bulk email senders to strictly adopt Domain-based Message Authentication Reporting and Conformance (DMARC). In other words.

If you’re not familiar with the procedure, using DMARC means inserting special TXT records in the DNS for your custom domain which tell receiving email servers how to dispose of messages which don’t comply with two other policies you should have already set up for your domain:

  1. SPF (Sender Policy Framework) which tells the world which sending servers are allowed to send email for your domain.

  2. DKIM (Domain Keys Identified Mail) which authenticates messages sent by the trusted sending sending servers for your domain.

Setting all three involves modifying the DNS records at your domain’s DNS provider as well as modifying certain some settings at your email provider.

If your email provider is Google Workspace, see:

If your email provider is Proton, see:

So far, I haven’t been able to find out how to set up DMARC for Apple as an email provider. Assuming you have iCloud+, then adding a custom domain to personalize your iCloud email addres(s) is covered at: … but I’d sure appreciate it if someone can tell me how to set up DMARC for it – I’m not looking forward to spending a lot of “quality time” with Apple Support on this.


The new stricter SPF/DKIM/DMARC requirements are having some unintended side effects. If you have an email address at some organization (e.g., which forwards to your regular email address, whether you get those incoming messages or not may depend upon exactly how the messages get forwarded (and whether that breaks DKIM or not).

If you send outgoing email through a 3rd-party domain, your messages could be unexpectedly bounced if you don’t use the proper SMTP relay. If you use an “” address for sending messages (as well as receiving forwarded messages), you’ll need to configure your outgoing mail server to be the ACM SMTP Relay service now so that your messages won’t be rejected by Google.

[So far, Microsoft doesn’t yet seem to be rejecting incoming message which do not have SPF/DKIM/DMARC completely specified.]

In this article, at around the half-way mark, the author includes a screen shot of the DNS record modifications needed. (Note that this article is from 2021 when this feature was in beta, but the posted technique makes sense. It would seem unlikely that Apple has changed the architecture since then.)

1 Like

To (hopefully) finish up this discussion, here is a link to the Joint Cybersecurity Advisory with specific recommendations for implementing a domain’s DMARC security policy … and what the consequences are if DMARC isn’t properly implemented.

[Note that having proper SPF and DKIM setups are prerequisites.]

I had this issue earlier in the year, particularly with a few companies that do business with me. Emails that they were sending could not be sent to me saying there was a DMARC issue. This seemed strange as there had been no issues in the past.

So I thought it was at my end and spent quite a bit of time attempting to troubleshoot this problem. I discovered that the problem was with my iCloud account. Emails sent to my gmail account were sent okay.

I asked one of these companies to send the log and that showed it was an Apple caused matter.

I spoke to Apple and was told it was not caused by Apple. But within 24 hours this problem was no longer a problem. Clearly Apple had done something but refused to say what.