How to structure email request class for different types of emails requiring different rendering params?

Currently, my notification request is like this:

public class EmailRequest{
  public enum EmailType{
    TYPE_1,
    TYPE_2,
    ...
  }
  EmailType emailType;
  String toAddress;
  EmailRenderer renderer;
}

where EmailRenderer is an interface

public interface EmailRenderer{
  EmailMessage render()
}

Now, each type of email has a separate implementation of the renderer interface and each implementation contains some rendering data that has to be provided by the client. This data can be different for each implementation.

Example:

public class Type1EmailRenderer implements EmailRenderer{
  String param1;
  String param2;
  @Override
  EmailMessage render(){
    //rendering logic using the params
  }
}

But, it seems redundant to me for the user to set the email type and renderer as well. Choosing the renderer should automatically get me the emailType. How should I restructure the request to be free of this redundancy? Also, can I use any design pattern for providing the renderers to my users?