Questions about upcoming Google DMARC/DKIM requirement

[danzingone]

I didn't understand the second sentence of Sonic's email message about the Feb 2024 changes. Specifically about whether or not this email applies in certain circumstances....

Did you mean If I DO " send email using a third-party email client such as Gmail or Hotmail using your sonic.net email address ..." can I disregard the notice?

Or did you mean If I DO NOT "send email using a third-party email client such as Gmail or Hotmail using your sonic.net email address ..." can I disregard the notice?

Thanks!

[virtualmike]

My emails go out with @sonic.net as the address.

Most likely, yes, but the Sonic team has taken care of it for you, so you won't need to take action.

[kgc]

I didn't understand the second sentence of Sonic's email message about the Feb 2024 changes. Specifically about whether or not this email applies in certain circumstances....

If you only send and receive mail using our servers then you should have nothing to worry about. A client like gmail is a special case of that, but from our perspective is the same, it just needs to be configured to send mail for that profile through our servers. The real issue would be if you were using something like Shopify to run an online business but it was configured to send email from "@sonic.net".

[mjrichards]

"If you only send and receive mail using our servers then you should have nothing to worry about. A client like gmail is a special case of that, but from our perspective is the same, it just needs to be configured to send mail for that profile through our servers. The real issue would be if you were using something like Shopify to run an online business but it was configured to send email from "@sonic.net". "

The change or "upgrade" - it IS essentially a security upgrade, right? - feels very rushed, considering we have adjunct internet entities to consider, and Sonic was careful to tell us in the cover announcement which we all received that they don't have the person-power to help an individual user figure out what they need to do.

Please explain in detail exactly what this means:
"A client like gmail is a special case of that [only send and receive mail using our servers], but from our perspective is the same, it just needs to be configured to send mail for that profile through our servers."

My frustration – with what I here-to-fore considered good service from Sonic – is:
1) Unclear writing - such as the first paragraph or indeed most of the writing in that email document Sonic sent us all a few days ago
2) Little or no explanation of the exact meaning certain terms
3) Puzzlement over what exactly have I been paying FOR in my monthly bill for email service, which included a Sonic personal email address.
4) The rushed feeling for this roll-out, considering many of us –"I" - don't understand many of the terms used to explain things in answers given or the trade-offs involved or even the hazards
5) for instance, I don't remember why I'm paying for a Sonic email address that I'm not even using, as it turns out. Would I regret not having a Sonic email address as a result of this change or "upgrade"?

[annkay]

Does sonic reply on these forums or is it only customers complaining to each other?

I send and receive email through the Mac Email client. Is that considered third party?

Sonic is not the registrar of my domains, how does that affect things?

Sonic's email said changes coming in February, but as of 4pm yesterday I can no longer send or receive emails from my domains via my sonic wifi - no problem on cellular or other networks. The timing of making changes and not providing support is horrendous. Who exactly am I supposed to contact if I can no longer send or receive email and Sonic can't support htese "advanced email problems"? The email we were sent also says blah blah only applies if you send 5000 or more emails. Well I never have and now I can't send any.

Frustrated, aggravated, and considering another provider,
JK

[ngufra]

From what i understand the timeline is not imposed by sonic but by google.
sonic did what google requires so if you use their servers everything goes smoothly.
If you use webmail or a thick email client on your computer that is configured to connect to sonic smtp mail server, you are fine.
if you use a third party (the example was shopify) software that sends email on your behalf but from their servers, then there may be issues where google would detect the discrepancy where the mail claims to be from sonic but does not have the expected header or has one but from the wrong domain. google would the refuse to deliver the message.

[lr]

Does sonic reply on these forums or is it only customers complaining to each other?

They frequently reply. One example is looking for users whose username is green instead of blue, those are Sonic staff (but some Sonic staff may also have blue user names, not sure).

I send and receive email through the Mac Email client. Is that considered third party?

Depends on how you have configured your Mac email client. If you have configured it the usual way that is documented on Sonic's web pages (which is to send mail via mail.sonic.net), and if you only use your @sonic.net e-mail address, then you are not affected by any of this.

Sonic is not the registrar of my domains, how does that affect things?

I'll go over my interpretation of things in the next message.

Sonic's email said changes coming in February, but as of 4pm yesterday ...

Sonic is not changing anything. What is changing is that some of the largest recipients of email (that being Google = gmail.com and Yahoo) are changing how they receive e-mail, and are forcing people who want to send e-mail to their users to follow the DMARC standard in some cases. By the way, the DMARC standard has existed since the early 2010s, but people have just ignored it until now.

If your e-mail on Sonic WiFi doesn't work, that's sad, but it has nothing to do with these DMARC changes.

[lr]

So here's my summary of what I have done; I would love people to critique whether there are any misunderstandings, or critique what I did wrong.

To begin with, e-mails that are sent with a @sonic.net From address and through the outgoing mailer at mail.sonic.net are completely unaffected, and users don't need to do anything about those. Conversely, it is no longer possible to send e-mails with a @sonic.net From address through any mailer other than mail.sonic.net. I consider this to be a good thing, since it reduces the chance that a Sonic user is wrongly accused of sending spam. We've never done that and aren't planning to start, so we're good there.

We use 3 different domains, 2 of which have their DNS run by Sonic. We today send all our mail for these domains through mail.sonic.net; in the past I had also used an outside mailing service (I think it was sendgrid), but I gave up on the complexity of it. For all these domains, one needs three things now:

• Have an SPF record in the domain's DNS that says that mail for this domain is allowed to come from mail.sonic.net. Here is what mine looks like: "v=spf1 include:mail.sonic.net -all". I have also seen it with "~all" at the end (which is less strict). If you use an outside mailing service, you would have to add it in the SPF record too, or remove the "-all" at the end (which is not recommended). I don't know whether Sonic would automatically add that SPF record for domains they serve; I did it myself long ago.
• Sign all outgoing mail with DKIM. For mail that is sent through mail.sonic.net, that is automatically taken care of. The DKIM signature relies on a <selector>._domainkey.sonic.net DNS record, which needs a specific selector. Again Sonic has taken care of that already. For the domains where Sonic is our DNS provider, I see that they added a net23._domainkey.<my_domain> DNS record, which is a CNAME to net23._domainkey.sonic.net. I don't know whether that cname record is even necessary (since the DKIM signature in the mail header clearly points at Sonic's domainkey record), but maybe some e-mail receivers need it. For the third domain, I'll add that CNAME record myself. If one uses an outside mail service, this gets more complicated.
• Have a _dmarc record in the domain's DNS. This is the only thing that's new. And it is easy to add: Go to whatever DNS server management interface, and add a TXT record at _dmarc.<my_domain>, which says "v=DMARC1; p=none; rua=mailto:postmaster@<my_domain>;". Use whatever e-mail for the error message you want, but it has to be within the same domain.

So in summary: For every domain that you use in From e-mail addresses, you need to have an SPF TXT record and DMARC TXT record, and while you are at it, adding the DOMAINKEY CNAME record for DKIM is easy, and may do something useful. If you use Sonic's DNS, the SPF and DOMAINKEY records may be automatic, but the DMARC record requires user intervention. If you use an outside mail sender, those are more complex.

[lr]

A few more random observations, probably can be ignored:

I like the idea of setting the DMARC record to p=reject or p=quarantine, because it gives guidance to e-mail receivers to throw spam sent by others with my e-mail address away. But I don't know whether it really helps, because the receivers are free to ignore it. For example, Microsoft Outlook ignores reject and treats it as quarantine. Also, it means that if I make any mistake in my SPF and DKIM records, I can't send mail any longer, and I don't trust myself that much. With well-behaved e-mail receivers this should be unneccessary anyway: If my SPF record says that mail from me is only to come through mail.sonic.net, and if my password (or in general authentication) at Sonic is well protected, then no spam from my e-mail address can exist anyway.

I don't know whether the RUA e-mail address on the DMARC record is strictly necessary. Personally, I would prefer to use a RUF address (and deal with spam reports 1-by-1 instead of in an XML summary), but supposedly RUF is de-facto unimplemented. Most amateurs won't know how to handle the reports that go to the RUA address anyway, so they could set it to be archived away and only looked at when absolutely needed.

[danzingone]

I didn't understand the second sentence of Sonic's email message about the Feb 2024 changes. Specifically about whether or not this email applies in certain circumstances....

If you only send and receive mail using our servers then you should have nothing to worry about. A client like gmail is a special case of that, but from our perspective is the same, it just needs to be configured to send mail for that profile through our servers. The real issue would be if you were using something like Shopify to run an online business but it was configured to send email from "@sonic.net".

Does "using our servers...you should have nothing to worry about" mean that if I am using my sonic.net addresses in Apple Mail, it should be ok, as long as I originally set up Apple Mail using Sonic's instructions for IMAP and SMPT? (I'm simply an end user, not a professional, so I appreciate your taking the time to explain questions than may seem very basic.)