Why are these records important?
Delivery of Site Automation Emails
Not only is email authentication a global recommendation for email delivery compliance, but it is also crucial to ensuring the automation (autoresponders & workflow) of emails sent from your Siteglide site. To ensure the best chance of delivery to a recipient's inbox, once emails are triggered from Siteglide and sent out by SendGrid.
If you are currently trying to troubleshoot the non-delivery of your automation emails please go through the link below or here:
Email Security & Delivery Best Practise
Google (Gmail) and many other mail providers are sniffing incoming mail for SPF, DMARC and DKIM alignment. If any of these records fail, the usual action is that the edge server refuses the email with an error message (sent to the sender’s mail provider).
An example message may look like this:-
“550, "5.7.26", " Unauthenticated email from //domain-name// is not accepted due to domain's DMARC policy. Please contact the administrator of //domain-name// domain.”
Note: In this case, the error message quotes the DMARC policy, but the DMARC record was fine - it was the DKIM record that was incorrectly formatted, so it failed. DMARC is linked to DKIM. DMARC suggests what to do with mail when the DKIM or SPF records don't pass authentication and the email is not seen to be legitimate.
Normally, all three records will be written to the DNS zone, but there is one exception. DKIM has two parts (a public/ DNS record and a private key which cannot be seen via a lookup and is normally installed on the server by the hosting server provider - in our case, pOS).
The golden rule with all of these public (DNS) records is that they must be written in the DNS zone where the authoritative nameservers are pointed (e.g. AWS, GoDaddy, etc.) and the DKIM private key must be installed server-side on the server that sends the mail.
For this document, we used: https://dmarcly.com/tools/
You can generate the record, copy and paste it into the DNS zone and (after propagation, set TTL to 600) check it using the same toolbox: https://dmarcly.com/tools/spf-record-checker
SPF
NB - A Records used for mail are entirely optional and the record will pass without these.
Select “fail” for the Policy section.
Click on Generate and you get this:-
Go into the relevant DNS zone and add this record as a TXT record (no host) with a TTL of 600 (to speed up verification) and the record in the “Value” field. Save. Wait 10 mins.
Check using the DMARCLY checker (toolbox).
DMARC
This is very similar to the SPF; you usually will only need to complete the first two fields but if you want this record to work across sub-domains, you’ll need to add that in.
The policy must be set to reject; aggregate email must be provided but does not need to exist. I always use dmarc@{domain}; if your client wants to receive DMARC reports (they’re daily!!!), use a valid email address.
Unless you know what you're doing, you can leave all the other options blank.
Click on generate....
DKIM
This is the exception to the rule: DKIM has two parts.
Public (DNS) record
Private (server-side) key
Important! The mail sender must generate the DKIM record.
What does this mean?
If the mail server/provider is GoDaddy and the NS is fully delegated to Siteglide AWS, the private key will be generated/ supplied/ installed by GoDaddy.
NB: If your site is not fully delegated to Siteglide, the public DNS record must be written externally, where the DNS is controlled.
They should then provide a public (DNS) key which will look like this:-
default._domainkey.domain.com TXT "v=DKIM1; k=rsa; p=ZIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw8XLZWiCYnb5Q0rpxWmqDoKDtWWs80KHIiHRqqwSI5aLE7jTr5IZYLDikQKstmZakMagv1bDsVuSehvT5SGt/RmcUfrxP+t7RzqFdcuU1cDPps40KBeUViie3ZMiS3N+1SWtScGVuYmDL40sx2m7v4G0kq2pitCG4XfWOKLB9zvpdRqKbT0vzhAAAD3SarTwjgzY2TA/5XQbjXBIenNeCzoDtMgoY0TqwL024cgwcE+NvyaAAnIbdteqkOIkJ2mjyXrh3s+3ujXE7yOEb/HijDFRoeSpkDWgFdoPNlYjsNayVqC1t0lFSo/nSSUgByOp7wk61Bj2srQqNQIDpowN"
Let’s break this up:-
In the DNS zone a new TXT record needs to be created as follows:-
Host: default._domainkey (do not include the domain as this will get added by Route53.
Value: v=DKIM1; k=rsa; p=ZIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw8XLZWiCYnb5Q0rpxWmqDoKDtWWs80KHIiHRqqwSI5aLE7jTr5IZYLDikQKstmZakMagv1bDsVuSehvT5SGt/RmcUfrxP+t7RzqFdcuU1cDPps40KBeUViie3ZMiS3N+1SWtScGVuYmDL40sx2m7v4G0kq2pitCG4XfWOKLB9zvpdRqKbT0vzhAAAD3SarTwjgzY2TA/5XQbjXBIenNeCzoDtMgoY0TqwL024cgwcE+NvyaAAnIbdteqkOIkJ2mjyXrh3s+3ujXE7yOEb/HijDFRoeSpkDWgFdoPNlYjsNayVqC1t0lFSo/nSSUgByOp7wk61Bj2srQqNQIDpowN
NB: TXT Records have a 256-character limit. Therefore, long values should have "" added in the string, which allows AWS to still read it as a single string.
Note: Depending on the mail server you or your client uses, the host might be s1._domainkey, s2._domainkey or default._domainkey (it just depends on the server). Here, we are using default._ in our example.
Save the new DNS record with a TTL of 600. Wait a few minutes and then check back using the DMARCLY tool.
If you get three successes, you’re good to go and mail will be delivered without issues.
Do, however, note some organisations' IT departments may have additional security setup for receiving emails that could prevent delivery even after implementing SPF, DKIM & DMARC is implemented.