How does PRIMARI.NET configure SPF, DKIM and DMARC?

The idea

When you order email, you usually just want it to work.

You do not want to learn acronyms or copy long DNS values by hand.

That is why PRIMARI.NET treats SPF, DKIM and DMARC as a natural part of email configuration.

If email and DNS are both at PRIMARI.NET

The panel can prepare the required records in Primary DNS.

A normal setup includes:

• SPF at the root of the domain;
• DKIM using the primari._domainkey selector;
• an initial DMARC policy with v=DMARC1; p=none.

The system does not aggressively replace existing records. If SPF, a different PRIMARI DKIM record or a custom DMARC already exists, it is preserved and can be reviewed.

If DNS is external

Email can still be hosted at PRIMARI.NET.

In that case, the records must be published at the external DNS provider.

The panel shows the values to copy:

• Host;
• Type;
• Value.

The DKIM private key is never shown.

Why SPF is simpler at PRIMARI.NET

When email only leaves through PRIMARI.NET servers, the recommended SPF value is stable because the outgoing IP addresses are controlled by us.

For many customers, SPF is the first useful and easy-to-maintain step.

DKIM and DMARC still add extra trust.

What if these records are missing?

Email may work, but some receivers will trust it less.

You may see spam placement, security warnings or problems with stricter services.

It is also harder to protect the domain against impersonation.

A cautious setup

PRIMARI.NET does not start DMARC with an aggressive policy.

The initial value is:

v=DMARC1; p=none

This gives you DMARC without asking receivers to reject legitimate mail by mistake.

When to ask for help

If external services also send email for your domain, such as newsletters, invoices or CRM systems, it is worth reviewing the setup before changing SPF or moving DMARC to a stricter policy.

PRIMARI.NET can help you keep the configuration coherent.