SPF
SPF (or Sender Policy Framework) is one of the most commonly used forms of authentication. SPF sort of functions like a permission slip. Your domain lists servers that are authorized to send on your behalf and recipient email servers check who is sending against that "permission slip"
To ensure the best level of deliverability while using rezora, we strongly recommend making sure your SPF record is configured in a way to allow rezora's sending servers to send on behalf of you and your agents. Without this setting in place, receiving email servers may be less trustful of the emails you are sending, potentially causing degraded deliverability.
This is done by adding include:sendgrid.net before the final all mechanism in your SPF record.
For example, if your existing SPF record is:
- v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com ~all
the new record might look like:
- v=spf1 a mx include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
DKIM
If SPF is like a permission slip, DKIM is more of a secret passphrase/signature. It is a digital signature added to outgoing messages that lets receiving servers know that the email is actually from you (not someone posing as you).
You may need to see if your domain has DKIM set up. DKIM is a little more complicated to set up than SPF as we need to generate a unique signature to share with your team directly so they can set it up.
If you do have DKIM set up, please let us know so we can loop in our engineering team to generate and send your team what they need.
Email us at support@rezora.com if you have DKIM for your domain and we'll get to work getting you the information that you'll need!
DMARC
DMARC is a special set of instructions that tells recipients what to do with an email if it doesn't match your SPF and DKIM setup.
As of February 2024, Gmail and Yahoo require a DMARC policy in place for any domain that ever sends more than 5000 emails out in a given day. Sending without a DMARC policy (as well as SPF/DKIM to support it) can result in your emails bouncing or being treated as spam.
A DMARC record tells receiving servers how to handle an email that comes in that doesn't align with the DNS record's existing SPF and DKIM setup. It can be set up to "reject" (bounce) or "quarantine" (send to spam or junk) an email, or, while being established, it can be set to "none" which would not affect emails that don't pass DMARC.
If you do not currently have a DMARC policy in place, we recommend setting one up, even if it is putting the bare minimum in place, allowing non-authenticated email to be delivered.
Here is an example of a "monitoring" DMARC policy ("DOMAINGOESHERE.com" as a fake value, to be replaced by your domain's information):
| TYPE | HOST | VALUE |
| TXT | _dmarc.DOMAINGOESHERE.com | v=DMARC1; p=none; |
If you do not have a DMARC policy in place currently, we advise putting one like this in place for your domains. You can then work on refining and fine-tuning your DMARC record later. DMARC policies can and likely should be set up in more complex ways to add monitoring, reporting, and control the percentage of total emails from your servers that are subject to these settings.
You can check if your domain has a DMARC policy in place using a tool like MXToolbox's DMARC checker tool here: https://mxtoolbox.com/dmarc.aspx
Email us at support@rezora.com if your technical team has any questions regarding what is needed for proper authenticated sending from rezora!