Background

The Journyx JX hosted environment has the ability to send out emails through the Journyx email server, aspmail.journyx.com. To ensure emails sent via your Journyx JX cloud site comply with authentication standards and sending polices enforced by major email providers, you can connect your email sending domain to Journyx. The domain connection process involves setting up three separate DNS record types in your DNS provider's settings: DKIM, SPF, and DMARC.


This article provides an overview of what these records are and how their associated authentication protocols work.



Impact on your Journyx JX cloud site

While DKIM, SPF, and DMARC are not strictly required to send emails via Journyx JX, you cannot send emails with your domain in the From Address (e.g., timetracking@example.com) without it being classified as SPAM until you connect that domain to Journyx by setting up SPF. Adding DKIM will also increase email deliverability for that domain.


Impact on email performance

Most inbox service providers prefer emails authenticated by DKIM and SPF. Emails sent without DKIM authentication or SPF are more likely to bounce, quarantine, or be categorized as spam. Quarantined emails will appear as delivered in Journyx JX, but will not be visible to most recipients, so it is highly recommended that you set up DKIM and SPF to improve deliverability.


Understanding SPF

SPF (Sender Policy Framework) is an email authentication standard used to verify that the sending email server is authorized to send email on behalf of a specific domain.

In order to authorize Journyx's mail server (aspmail.journyx.com) to send on behalf of your domain, you will need to add the following to your domain's SPF record:

a:admin.journyx.com

Learn how to add these records by following the instructions in this article.


Understanding DKIM

DKIM, or DomainKeys Identified Mail, is an email authentication method that uses a digital signature to let the receiver of an email know that the message was sent and authorized by the owner of a domain.


Once the receiver determines that an email is signed with a valid DKIM signature, it can be confirmed that the email's content has not been modified. In most cases, DKIM signatures are not visible to end-users, the validation is done on a server level. If DKIM is used together with DMARC and/or SPF, you can protect your domain against malicious emails sent from domains impersonating your brand.


How to set up DKIM in Journyx
To set up DKIM in Journyx, you will need to reach out to support@journyx.com to receive your unique DKIM CNAME record that will need to be added to your domain's DNS provider. Once you configure your DKIM record in your DNS provider using a public key that Journyx provides you with, a receiving mail server will be able to verify the signature of your sent email that's associated with your domain.


Learn how to add these records by following the instructions in this article.


Understanding DMARC

DMARC, which stands for "Domain-based Message Authentication, Reporting & Conformance", is an email authentication policy, and reporting protocol. It builds on SPF and DKIM protocols, adding linkage to the author ("From:") domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.


By configuring a DMARC record, inbox providers can confirm how to process emails sent from your domain that do not pass SPF and DKIM checks.


DMARC Policy Values

 A DMARC policy can be defined by adding a TXT record in your DNS provider settings, with a value that can include the following semicolon-separated policies:

  • v: the DMARC version.
  • p: the policy type that dictates how to process emails that do not pass. The policy can be set to one of the following types:
    • none: used to collect feedback and gain visibility into email streams without impacting existing flows.
    • quarantine: filter emails that do not pass authentication into the recipient's quarantine.
    • reject: bounce emails that do not pass authentication.
  • sp: used to apply a policy to a subdomain of the DMARC record.
  • pct: the percentage of total unique sends that failed authentication to apply this policy to. For example, if your DMARC record included p=reject; pct=25, and 100 emails failed authentication, only 25 of them will be bounced, while the other 75 will be delivered to their recipients.
    • Defining this property can help slowly ramp up your authentication policy to ensure it's working as expected.
    • Note that this parameter is sometimes ignored by certain inbox service providers.
  • ruf & rua: two optional parameters that specify an email address to send DMARC reporting data to. These must be provided in URI mailto format (e.g., mailto:reporting@example.com). The reporting data that's sent differs based on the parameter:
    • rua: an aggregate report of all your domain traffic.
    • ruf: failure reporting data that includes redacted copies of individual messages that failed authentication.
  • adkim & aspf: specifies the alignment mode for DKIM and SPF. These should both be set to r (i.e., a relaxed alignment). A relaxed alignment should be the default setting for DMARC for DNS services.

DMARC Example Policies

 

Neutral policy

v=DMARC1; p=none;

This is an example of a neutral DMARC policy with no additional parameters. A neutral policy is useful for senders who're just starting to get familiar with DMARC. This is the bare minimum for DMARC to function.

Strict policy with aggregate reporting

v=DMARC1; p=reject; rua=mailto:reporting@example.com;

The example above defines a strict DMARC policy to bounce any emails that fail authentication, and provides an email address to send aggregate reporting data to.

Quarantine policy with failure reporting

v=DMARC1; p=quarantine; pct=25; ruf=mailto:reporting@example.com;

This example defines a policy that will quarantine 25% of emails that fail authentication, while the other 75% of emails that fail authentication will be permitted for delivery. The policy also provides a reporting address where an individual notification email can be sent for each email that fails authentication.

Defining a value for the pct property can allow you to test a random sample of messages that failed DMARC to allow you to check that legitimate emails are still being delivered properly.