Vega takes several steps to protect your emails and maximise delivery rates, but there are also actions you, as the domain holder, need to take. This guide explains what those are and how to set them up.
Domain Authentication
Emails are sent via Vega using our email provider, SendGrid. Domain authentication tells receiving email providers that SendGrid has your permission to send emails on your behalf. You grant this permission by adding DNS records that point from your DNS provider (such as GoDaddy, Rackspace, or Cloudflare) to SendGrid.
This has a significant positive impact on your sender reputation and email deliverability. Email providers are suspicious of messages that lack domain authentication because, without it, they cannot verify that the message genuinely came from you. Authenticating your domain signals that the email is legitimate, making it far less likely to be filtered or blocked — and less likely that your recipients will mark it as spam.
If you have not done so already, please get in touch with us to set this up by providing your domain name and host. We will then send you CNAME records to be added.
Reading Your Email Header
The email header contains technical information about how a message was sent and processed, including the results of SPF, DKIM, and DMARC checks, and the Envelope From (return path) address.
To view the header:
- Gmail: Open the email, click the three-dot menu, and select "Show original."
- Outlook: Double-click the email to open it in a new window, then go to File > Properties and check the Internet headers field.
- Other clients: Look for a "View source," "Show headers," or similar option.
Envelope From (Return Path)
The Envelope From address tells receiving mail servers where to send bounces and delivery failures. Think of it like a return address on an envelope — it is used to route mail behind the scenes and is not usually visible to the recipient. When you have added the CNAME records provided for your domain authentication, this specific domain will be your envelope from address.
SPF (Sender Policy Framework)
SPF is an open standard designed to prevent sender address forgery. It works by checking that the IP address used to send a message is authorised to send mail on behalf of the domain listed in the Envelope From address.
SPF is implemented by adding a TXT record to your domain's DNS settings. This record lists the IP addresses and domains permitted to send email on your behalf.
What to do
If you already have an SPF record, you will need to add your specific domain provided in your CNAME records to it before the all mechanism.
Such as:
include:em1234.mydomain.com
Important: Do not create more than one
v=spf1record for a domain. If you already have an SPF record, only add theinclude:values — do not create a new record.
If you do not have an SPF record, create a new TXT record with the following (substituting your specific domain provided):
v=spf1 include:spf.protection.outlook.com include:em1234.mydomain.com ~all
DKIM (DomainKeys Identified Mail)
DKIM uses public-key cryptography to sign outgoing emails. Like SPF, it is implemented with a DNS record — but instead of listing permitted senders, the DKIM record publishes a public key that receiving servers can use to verify that the message genuinely came from your domain and was not tampered with in transit.
Where SPF checks the sending IP address, DKIM checks a cryptographic signature applied to the message headers (including the From address). Together, they provide much stronger protection against spoofing.
What to do
DKIM is set up as part of the Domain Authentication process described at the top of this guide. When you contact us to set up domain authentication, we will generate a unique set of CNAME records for your domain via SendGrid. These records handle both domain authentication and DKIM signing in one step — you do not need to configure them separately.
If you have already completed domain authentication with us, DKIM is already in place for your domain.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC builds on top of SPF and DKIM. It allows you to specify what should happen to emails that fail those checks, and gives you visibility into who is sending mail on behalf of your domain.
The problem DMARC solves: email spoofing
Email spoofing is the practice of sending email with a forged From address. Without DMARC, there is no standard mechanism to instruct receiving servers what to do if SPF or DKIM checks fail — the message might be delivered, filtered to spam, or bounced, with no consistency and no feedback to you as the domain owner.
How DMARC works
DMARC is implemented as a DNS TXT record. It tells receiving servers how to handle failures and where to send reports. An example record looks like this:
v=DMARC1; p=quarantine; rua=mailto:dmarcreports@yourdomain.com; ruf=mailto:dmarcreports@yourdomain.com
Replace dmarcreports@yourdomain.com with a real email address on your domain. This address will receive DMARC reports, so it is best to create a dedicated address for this purpose rather than using someone's work inbox.
DMARC tags explained
| Tag | Description |
|---|---|
v=DMARC1 |
Identifies this record as a DMARC record (required). |
p= |
The policy — what to do when checks fail (required). |
rua= |
Where to send aggregate (summary) reports. |
ruf= |
Where to send forensic (detailed) reports. |
Policy options (p=)
-
none— No action is taken on failing messages; they are delivered as normal. Failures are still included in reports. Use this initially to monitor your mail streams without affecting delivery. -
quarantine— Failing messages are sent to the spam folder. Failures are included in reports. -
reject— Failing messages are rejected outright and will not be delivered. Use this only once you are confident you have identified every service sending email on your behalf and have DKIM signing in place for each.
DMARC reports
-
Aggregate reports (
rua) are sent daily and provide a summary of authentication results across your domain. -
Forensic reports (
ruf) are sent in real time and include detailed information about individual failures.
These reports are invaluable for understanding your mail streams, identifying unauthorised senders, and tuning your configuration over time.
How It All Fits Together
The diagram below shows the full email delivery process and where each security check takes place.
Checking Your Configuration
Once you have added your DNS records, you can use MXToolbox to verify that your SPF, DKIM, and DMARC records are configured correctly.
Note that DNS changes can take up to 48 hours to propagate, so if your records do not appear immediately, allow some time before rechecking.
Comments
0 comments
Please sign in to leave a comment.