Email Security

There are various things that vega does to improve the security of your emails and improve your email delivery rates. 

There are also things, you as the domain holder needs to do to help with email delivery and ensure the emails being sent are recognised as having permission to be sent on your behalf.

 

Domain Authentication

Emails are sent from vega and via our email provider, SendGrid. Domain authentication shows email providers that SendGrid has your permission to send emails on your behalf. To give SendGrid permission, you point DNS entries from your DNS provider (like GoDaddy, Rackspace, or Cloudflare) to SendGrid.

This has a huge positive impact on your reputation as a sender and your email deliverability. Email service providers distrust messages that don't have domain authentication set up because they can not be sure that the message comes from you. Explicitly stating that it comes from you increases your reputation with email service providers which makes it much less likely that they will filter your mail and not allow it to get to your recipient's inbox, which increases your deliverability. You are also explicitly showing your recipients that this email comes from you, so they are less likely to mark your mail 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.

 

Email Header

In an email, you can find the Email Header by selecting "Show Original" > "View Message Source" > "Show Headers" or a similar option depending on your email client. In Outlook, double click your email to open it in a new window, click "File" > "Properties" and check "Internet headers"

This provides information on your SPF, DKIM, and DMARC results, as well as the Envelope From (return path) address.

The Envelope From address informs receiving email servers where to deliver replies and where to send bounces. Think of the Envelope From as the return address on a paper letter’s envelope—the postal service does use this address to route mail; it’s there to establish the sending source of the letter.

The Envelope From is not usually displayed to a message’s recipient by default.

 

SPF

Sender Policy Framework (SPF) is an open standard aimed at preventing sender address forgery. 

SPF attempts to prevent email sending abuse by ensuring that the IP address from which a message was sent is authorised to send mail on behalf of the domain in the email’s Envelope From or return-path.

SPF is implemented by adding a TXT record to your domain’s DNS records. The TXT record specifies which IP addresses or domains are allowed to send emails on your behalf.

If you have an SPF record set for your domain already, you need to add the below values before the all mechanism of this record in order to authenticate email coming from vega. If you do not have an existing SPF record for your domain, you must create a TXT record with the below values, as well as your own mail server:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mail.vega.works ~all

Do not create more than one SPF1 record for a given domain. If you already have an SPF record, only the include: values need to be added to your existing record.

 

DKIM

DomainKeys Identified Mail (DKIM) uses public-key cryptography to sign a message. Like SPF, DKIM is implemented with a TXT record. Unlike SPF, the DKIM TXT record provides a public key that receiving mail servers can use to verify the authenticity of a message.

Remember, the problem with spoofing is forgery of the From address. However, by signing the From address, among other headers, and providing a public key to verify the signature, receiving servers can corroborate the authenticity of the sender.

 

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a powerful way to verify the authenticity of an email’s sender and prevent malicious senders from damaging your sender reputation.

To understand DMARC, let's first understand the problem DMARC attempts to solve: email spoofing.

Email spoofing is the practice of sending email with a forged From address. Note that an email actually has two From addresses: the Header From and Envelope From. DMARC is concerned only with the spoofing of the Envelope From (also known as the return path) address. 

DMARC relies on two authentication protocols to prevent spoofing: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). DMARC is like a framework for handling SPF and DKIM failures and reporting those failures to domain owners

• DMARC allows domain owners to specify what should happen if either or both SPF and DKIM checks fail. Neither SPF nor DKIM provides this functionality on their own. This means that without DMARC a sender has no say in whether a failing message is bounced, sent to a spam folder, or handled in some other way.
• A sender receives no feedback about SPF and DKIM failures without DMARC, so senders have little chance to combat or even understand the delivery trends of their domain, often called "reputation monitoring."
• SPF and DKIM are independent of each other, but neither provide thorough spoofing protection on their own.

Like SPF and DKIM, DMARC is implemented using a TXT DNS record. This record allows receiving email servers to fetch failure processing instructions from domain owners. An example DMARC record is:

v=DMARC1; p=quarantine; rua=mailto:dmarcreports@yourdomain; ruf=mailto:dmarcreports@yourdomain

The email address included in the mailto: should be a real email address in your domain to receive the reports. This should not be someone's work email, it is best to create an email address for this purpose only.

See below for further explanation on the tags and values used in the example above.

A DMARC record contains several tags separated by semicolons. Two of the tags are required, v (version) and p (policy).

• The version, v=DMARC1, tells receiving servers that the DNS TXT record is a DMARC record.
• The policy, p, can be one of three values, none, quarantine, or reject. DMARC policies are the mechanism domain owners use to specify how a receiving email server should handle SPF and DKIM failures.
  • p=none: No action should be taken. Even if a failure occurs, the message should be delivered. Though no action is taken on the message, the failure is included in reports sent to the domain owner.
  • p=quarantine: Failures should be quarantined. This usually means the message is sent to the spam folder. Again, the failure will be included in reports to the domain owner.
  • p=reject: Failures will be rejected. This usually means that the message will be deleted. The message may also be bounced to the Envelope From address. Use this setting when you’re absolutely sure you know every server and service that is sending email for your domain, signing is in place for each of these services, and you want any service claiming otherwise to be completely denied

Where do the failure reports go? The address assigned to rua= tells receiving email servers where to deliver aggregate reports. The address assigned to ruf= tells receiving email servers where to send forensic reports.

• Aggregate reports are sent daily by default and don’t include detailed information about individual failures.
• Forensic reports send detailed information about individual failures at the time of failure. The email address assigned to ruf must also use the domain on which the DMARC record exists.

These reports will give you the information required to evaluate and tune your mail streams, helping you determine exactly what services are sending mail on behalf of your domain.

 

See the image below for a visual representation of the email delivery process and the security checks made:

 

The website https://mxtoolbox.com/ can be used to check the details of your domain for the records described above.