Not using your domain to send emails? Protect it from spoofing

Even if you don’t use your domain to send emails, someone might try to use it to impersonate you. To prevent this, you must indicate that no one is allowed to send emails from that domain.

This can happen with domains you have purchased to protect your brand, domains you only use to display a website, or domains that redirect to another address. Even if you have never created an email account like contact@yourdomain.com, someone could try to use that address to send fraudulent emails pretending to be you.

The solution is to publish clear rules in the domain’s DNS records, indicating which services are authorized to use it.

How can they send emails if they don’t have access to your domain?

The address that appears as the sender of an email can be forged. It’s similar to writing a false address on the return of a letter: the appearance of an address does not prove that the message actually came from there.

This practice is known as email spoofing or sender impersonation. An attacker could send messages that appear to come from addresses like:

• billing@yourdomain.com
• support@yourdomain.com
• administration@yourdomain.com

They don’t need to access your panel or know your passwords to try it. The goal is usually to exploit the trust generated by the domain name to request payments, steal credentials, or distribute malicious files.

When someone receives one of these emails, their email service checks the domain’s DNS records to verify if the message was sent from an authorized server. If the domain doesn’t have clear rules, it will be more difficult to detect that the sender is fake and decide whether the message should be accepted, sent to spam, or rejected.

Your domain can be exposed even if it doesn’t have email accounts

Not using email with a domain can create a false sense of security. Precisely because no one reviews its configuration, it’s common for these domains not to have any specific protection against this type of impersonation.

This scenario is common in:

• Domains purchased to protect a brand.
• Variations of the main domain.
• Domains that redirect to another website.
• Domains used only for a landing page.
• Old domains that no longer send emails.
• Subdomains intended for internal applications or services.

For example, a company might work with mybrand.com, but also have registered mybrand.es to protect its name. Even if the second domain only redirects to the main website, it’s advisable to prevent someone from trying to send emails from administration@mybrand.es.

The three records you should know

SPF, DKIM, and DMARC form the authentication system that allows verifying if an email is authorized. However, not all are used in the same way when a domain doesn’t send messages.

You can check if your domain has these protection measures configured with tools like DMARC Domain Checker. You just need to enter your domain name to check its SPF, DKIM, and DMARC records and detect if any are missing.

SPF: indicates that no one is authorized to send emails from the domain

SPF is a DNS record that defines which servers are authorized to send messages on behalf of a domain.

When the domain should not send any emails, you can publish a policy indicating that no server is authorized:

v=spf1 -all

The part -all indicates that no server has permission to send emails from that domain. If someone tries to do so, the message will not pass the SPF check, and the receiving service can identify it as unauthorized.

It’s not the same as leaving the domain without an SPF record. If this record doesn’t exist, email services don’t clearly know who can send messages from the domain. However, with v=spf1 -all you explicitly indicate the following:

This domain is not used to send emails. Therefore, any message sent from it should be considered unauthorized.

DKIM: you don’t need a signature if you don’t send

DKIM adds a digital signature to the emails you send. The service receiving the message can verify that signature using a key published in the domain’s DNS records. This way, it can verify that the email comes from an authorized service and that its content hasn’t been modified during transmission.

If the domain is not used to send emails, there are no messages to sign, and therefore, you don’t need to configure DKIM.

What happens if you want to send emails?

In that case, you should activate DKIM. You don’t have to create the signature yourself: the service you use to send emails, such as your email provider, a newsletter platform, or an application, will provide you with the DKIM record you need to add to the DNS. If you use the email service of cdmon, you can check what individual DKIM is and why it’s important to configure it.

Each service can use its own key. Therefore, if you send emails from multiple platforms, you must follow the instructions of each one and add the DKIM records they provide.

DMARC: indicates what to do with emails that pretend to be from your domain

DMARC doesn’t reject emails by itself. It’s a rule that tells email services, like Gmail or Outlook, what to do when they receive a message that seems to be sent from your domain but doesn’t pass security checks.

For example, you can indicate that those emails should be rejected so they don’t reach their recipients.

In a domain that you don’t use to send emails, you can add this rule:

v=DMARC1; p=reject;

This rule is stored in a TXT record, a type of DNS record that allows adding written information to the domain. In this case, it serves to tell services like Gmail or Outlook what to do with emails that try to impersonate your domain.

You must add this record from the panel of the provider that manages your domain’s DNS. If you manage them in cdmon, check the guide on how to configure a TXT record.

Create a new TXT record and enter these details:

• Name or host: _dmarc
• Record type: TXT
• Value or content: v=DMARC1; p=reject;

It’s not necessary to write _dmarc.yourdomain.com completely if the panel automatically adds your domain name. Before saving it, check how the result is displayed: it should appear as _dmarc.yourdomain.com.

If you also want to protect subdomains, use this value:

v=DMARC1; p=reject; sp=reject;

The part sp=reject applies the same protection to addresses using subdomains, like support@store.yourdomain.com.

You can expand on how these mechanisms work together in the cdmon article on email security: SPF, DKIM, and DMARC.

Don’t confuse sending email with receiving it

SPF and DMARC records help prevent someone from sending emails pretending to be from your domain. MX records serve another function: they indicate which servers should receive the emails you get.

That’s why you should distinguish between two situations.

The domain doesn’t send, but does receive email

If you don’t use the domain to send emails but want to continue receiving them or redirecting them to another address, you can block sending through SPF and DMARC as we saw in the previous section. These records help prevent others from sending messages pretending to be from your domain.

To continue receiving emails, leave the MX records as they appear in the domain’s DNS. You don’t need to create others or add their content to SPF or DMARC.

Don’t delete or replace the MX records, as you would stop receiving messages.

The domain doesn’t send or receive email

If you don’t use the domain to send or receive emails, you can configure a record called Null MX. This record clearly indicates that the domain doesn’t have any email service and, therefore, doesn’t accept messages.

To configure it, access the panel from which you manage the domain’s DNS and create an MX record with these details:

• Name or subdomain: @
• Destination: .
• Priority: 0

If the domain already has other MX records, you will need to delete them, as they indicate that there are authorized servers to receive its emails. Do this only if you have verified that you don’t use any email account, alias, or redirection linked to the domain.

The Null MX is more suitable than leaving the domain without MX records. If you simply delete them, some servers might try to deliver messages to the website’s IP address. Instead, the Null MX directly informs them that the domain doesn’t receive emails and avoids those unnecessary attempts.

If you manage the DNS in cdmon, you can check the guide on how to configure an MX record. If the panel doesn’t allow entering a dot (.) as a destination, contact the support team before modifying the current records.

Recommended configuration according to domain use

Email Use	SPF	DKIM	DMARC	MX
Doesn’t send · Does receive	v=spf1 -all*	Not necessary	p=reject*	Maintain MX
Doesn’t send · Doesn’t receive	v=spf1 -all	Not necessary	p=reject; sp=reject	Null MX
Sends via a service	Authorize real servers	Configure the service’s key	Review before applying reject	According to the receiving service

* You should only use these policies if you have verified that the domain doesn’t send messages from forms, newsletters, applications, or other platforms.

Before applying a rejection policy, review all your sends

A domain may be sending emails even if you don’t use an inbox to do so. For example:

• WordPress contact forms.
• WooCommerce purchase confirmations.
• Automatic invoices.
• Reservation notices.
• Password recoveries.
• Newsletters and commercial campaigns.
• Application notifications.
• Customer service.

If you configure v=spf1 -all or DMARC with p=reject while your website or some service continues to send emails from the domain, those messages could be blocked even if they are legitimate.

Before changing the records, make an inventory of all services associated with the domain. If you discover any, you will need to authorize it through SPF, activate its DKIM, and ensure both are correctly aligned with DMARC.

How to protect a domain that doesn’t send emails in cdmon

If the domain’s DNS are managed in cdmon, you can review the authentication from the Control Panel.

Before modifying anything:

1. Confirm that no account, website, or external platform sends emails from the domain.
2. Check if the domain receives messages or uses redirections.
3. Save a copy of the current DNS records.
4. Review if SPF or DMARC records already exist. You should not create two SPF records or two DMARC policies for the same domain.
5. Configure the policy corresponding to the actual use of the domain.
6. Wait for the DNS changes to propagate and check the records again.

From ConnectiLogs, you can check the status of SPF, DKIM, and DMARC of your domains and detect if any configuration is missing.

If you’re not sure if a form, application, or external platform is sending messages, don’t directly apply a rejection policy. First, review the configuration or contact the cdmon support team.

Common mistakes you should avoid

Thinking that not having MX records prevents sending email

MX records are used to receive messages. Removing them doesn’t prevent someone from trying to show your domain as the sender.

Creating a second SPF record

A domain should only have one SPF record. If one already exists, you should modify or replace it as appropriate, not add another separately.

Applying p=reject without reviewing forms and platforms

Even if you don’t use email accounts, your website might send confirmations, notices, or automatic responses. An overly strict policy can block these legitimate messages.

Publishing a Null MX when you still need to receive messages

The Null MX indicates that the domain doesn’t accept any email. It will also prevent the functioning of accounts, aliases, and redirections.

Forgetting about subdomains

An attacker can also try to use addresses associated with subdomains. The sp=reject tag allows indicating a rejection policy for them.